It's probably no longer relevant, because you now choose the BTH way. But to answer your OP:
Peers attached to the same WireGuard interface in RouterOS cannot have overlapping Allowed Address values.
When you have multiple peers associated with wireguard1, and all those peers have 192.168.99.0/24 listed as part of their Allowed Address field, and you send something destined to 192.168.99.x using wireguard1 as outgoing interface, then this will be exactly the consequence that you'll observe:
When sending a packet to 192.168.99.x using wireguard1 as tunnel interface, WireGuard will go through the list of peers associated with wireguard1 and see whether anything listed in that peer's Allowed Address list matches the destination address 192.168.99.x. The first peer that satisfy that condition will be picked and the packet will be sent through the tunnel established between the router and that remote peer. The rest of the other peers will simply be ignored. Of all the peers having 192.168.99.0/24 in Allow Address only one will always be chosen (the first one found) to send the packet to.
It appears that with the current implementation, the chosen peer among the candidates satisfying the condition is the last one being edited and saved. When you performed the disable/re-enable action, you edited the peer and moved it to the top of the candidate list.
Please note that putting the IP address of the remote peer as gateway in the route like this:
does not have the effect that you intended. It's not because you put 10.111.100.5 there as gateway that the packet will be sent through the tunnel established between the router and the peer with the address 10.111.100.5. Or that if you put 10.111.100.6 there then the peer with the address 10.111.100.6/32 listed in Allowed Address will be chosen as gateway.
NO! Doing that only tell the router to choose wireguard1 as the gateway (because of the connected route dst-address=10.111.100.0/24 gateway=wireguard1 that also exists in the routing table). The next hop is wireguard1 is all that is known, not that the next hop is the peer 10.111.100.5 or the peer 10.111.100.6. Which peer is really selected next depends on the check done on the Allowed Address field of the peer, as I've written above.
Which means even if you've mangle rules or routing rules that select different routing tables for the destination 192.168.99.x, if the resulting gateway is wireguard1, then the packets will always be sent to the same peer.
When you don't have overlapping Allowed Address values between the peers, then there will be no case where multiple peers can satisfy a destination address. Which means there is no ambiguity, no uncertainty over which peer will be the selected one. This is what you should try to achieve!
Instead of wireguard1 + multiple peers, one for each remote site, you should create multiple WireGuard interfaces, one for each remote sites (wireguard-A to connect to site A, wireguard-B to connect to site B, etc...). Each of those interfaces only has one remote peer associated (where you can put all those non-/32 subnets 192.168.99.0/24 and 10.2.1.0/24). Then in your rtab-XXXX routing table set the default route destination 0.0.0.0/0 gateway wireguard-X (X being A, B, C, etc...).
The interface wireguard2 that you used to connect your client devices can stay as-it. But again, if you have multiple peers here, don't give those peers overlapping values under Allowed Address. And I see no needs for having 192.168.99.0/24 and 10.2.1.0/24 in them. Only keep one /32 per client to differentiate between them.
