I was actually intending the + to mean concat, although combining them with a different operator would work also to keep it to 32 bytes, but I think xor would be a better choice than addition anyway, so no 256 bit math operations are required.
Yes - so perhaps we should add XOR_A_with_B and XOR_B_with_A to the API (as these will be very easy to implement).
Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones,
I think sending two messages could be problematic as it opens up a potential attack vector where others might try to inject a message *between the two*.
although having an extra api call that retrieves messages without the size restriction might be good also so you only have to work within the limitations of the coins you are actually transferring between.
The point of the limitations is to be able to write "portable" ATs (that will work the same on on all platforms). The function number ranges 0x500..0x5ff and 0x600..0x6ff are reserved for writing "platform specific" API functions so that would be the appropriate way to implement a different kind of Message_From_Tx function (such as perhaps Message_From_Tx_In_A_To_AB).