Before eventually taking such extreme measures, enable logging using /system logging add topics=ipsec,!packet if you haven’t done that yet, then run /log print follow-only file=working where topics~“ipsec”, and let the Android connect with the working settings. Then Ctrl-C the /log print …, download working.txt from the router, delete it there to free the space, run /log print follow-only file=failing where topics~“ipsec”, and let the Android try to connect with the wrong settings. After some 5 seconds, Ctrl-C the /log print …, and download the other file. If reading those files gives you no hint, you can use the information in this post to send me your contact info if you’d rather send me those files privately than obfuscate them and post them here (the IP addresses are encoded in the hex bytes shown so it is a bit more complicated to obfuscate than when the addresses only appear in the human friendly notation).
I have just tested the same setup on the responder side - fqdn:s and fqdn:t do work as expected if another Mikrotik acting as an initiator identifies itself using these identities. Each row of the identity list on the responder side refers to a different mode-config row with a different address and everything works as expected, the initiator gets the correct address depending on what my-id I set on its only identity row.
/ip ipsec identity
add generate-policy=port-strict mode-config=s peer=t-chr-2 remote-id=fqdn:s
add generate-policy=port-strict mode-config=t peer=t-chr-2 remote-id=fqdn:t
So it looks as if the Android was behaving different in some regard - mine is 12 so I have to use an app for IKEv2 that does not support pre-shared key authentication, hence testing on it would not be relevant. It also seems that Mikrotik does not care about the formal correctness of the FQDN IDs any more.