Quick second thought: If we do deploy XMSS as an opcode instead of using taproot+WOTS, then the XMSS merkle branches should be directionless (lexi-sorted before hashing) like taproot trees. The reason is succinctness and privacy.
Vanilla XMSS must reveal the path of the WOTS leaf in the tree which, besides wasting blockspace, means that if you know the tree structure, you also know how many signatures that key has previously issued, and how many it has left.
A directionless balanced XMSS tree obscures that information, or at least makes it ambiguous. An observer who sees a merkle proof for this tree, can’t tell for sure without external data (like previous signatures) whether the signature they’re looking at is the first signature from this key, or the last, or any in between, even if they know the XMSS tree height.
For an unbalanced XMSS tree like in SHRINCS, simply seeing the merkle path length reveals the signature count. But it’s also impossible to tell a balanced directionless XMSS tree from an unbalanced one as an observer. Verifiers don’t need to know, as long as the WOTS signature and authentication path recompute into the correct root hash.
Wallets and users would be free to choose the XMSS tree height and structure on their own, but the final on-chain fingerprint will be mostly indistinguishable from case to case. A directionless XMSS signature from a balanced height=2 tree looks the same as the second signature from an unbalanced tree.