no, the via part is just not considered. it does not make much sense to try though as it is impossible to have multiple peers with the same AllowedIPs addresses set. if it would honor the via address and allow me to configure multiple peers with the same AllowedIPs setting some dynamic routing could be made possible but it is not. However, i do configure it like you described just for consistency reasons when looking at the routing tables.
i.e. i could have peer A at 172.16.1.1 and peer B at 172.16.2.1. peer A would have AllowedIPs=172.16.1.1/32,172.16.0.0/24 and peer B would have AllowedIPs=172.16.2.1/32,172.16.0.0/24 and i could decide which peer gets traffic for 172.16.0.0/24 using the routing table by setting the via address to either 172.16.1.1 or 172.16.2.1 respectively. however, as stated this is not even allowed as only one peer would be able to have that subnet in its AllowedIPs setting present.
Ahh. If you are using wg-quick, the the script automatically adds interface level routes to the routing table that would override any manual static routes. You could add a Table=off flag to the wg interface config, and then you won't have the automatically generated route table entries based on the AllowedIPs flags, and your manual routes will be respected.
i do not. i manually manage these routes all by myself using systemd-networkd... these routes are respected but the via address is ignored nonetheless. to repeat myself, the via part of the route is not considered; i even double checked this by reading the code and furthermore did a PoC if it could be done. as soon as the route hits the interface the packets get routed according to the AllowedIPs setting regardless of any via address set on that route. If you are inclined enough to do so you can try it yourself. set it to a non existing address and you will see it will be routed regardless... or even set it to the address of an existing peer that has it set in its AllowedIPs setting and you will notice the peer that has the packets destination set as AllowedIPs setting will get the packets. which makes some sense as return traffic would only be allowed to come from that peer anyhow. i.e. for incoming packets the routing table is not even considered at all (analog to reverse path filtering).
i.e. i could have peer A at 172.16.1.1 and peer B at 172.16.2.1. peer A would have AllowedIPs=172.16.1.1/32,172.16.0.0/24 and peer B would have AllowedIPs=172.16.2.1/32,172.16.0.0/24 and i could decide which peer gets traffic for 172.16.0.0/24 using the routing table by setting the via address to either 172.16.1.1 or 172.16.2.1 respectively. however, as stated this is not even allowed as only one peer would be able to have that subnet in its AllowedIPs setting present.