Inconsistent Route Handling Across Different Client Implementations

Dear list,

We arguably have a bit of an "exotic" setup, namely, we have one
interface with two addresses assigned (on the "client" side) and two
peers with the AllowedIPs in the respective subnets. Below is a
minimal ("client") configuration example for context (keys are
intentionally omitted):

[Interface]
Address = 172.16.100.2/24,172.16.101.2/28

[Peer]
AllowedIPs = 172.16.100.0/24
Endpoint = first.tld:51820

[Peer]
AllowedIPs = 172.16.101.0/24
Endpoint = second.tld:51820

The behavior after importing this connection configuration on various
clients leads to different results:

- Linux (wg-quick): Routing does work, kernel routes are used with the
correct "src" attribute set
- Linux (nmcli): Routing does not work out of the box because nmcli
generates a second set of routes with the same metric as the kernel
ones but without the "src" attribute being set. This can be fixed by
setting "Table = off" in the WG config. Moreover, I believe this is a
bug or at least an unfortunate coincidence that the same metric value
is used. An issue has been opened on NetworkManager's GitLab [0].
- Windows: Routing works; the "Table" attribute is not considered an
"Unknown attribute.", but has seemingly no effect.
- Android: Routing only works for the first subnet. Although the
entries in the main routing table are correct (again, kernel routes,
"src" attribute set), additional entries are created in secondary
tables ("local_network" and "tun0"), which take precedence due to a
bunch of policy-based routing rules.
- macOS: Same symptoms as on Android,  "Table = off" considered invalid

Are we trying to do something fundamentally against the design ideas
of WireGuard? Even if so, I would expect importing the same WireGuard
profile on different platforms to yield the same routing behavior.
Also, before you ask, the option of having multiple interface active
at the same time is not a option as this is not foreseen on all the
official (graphical)-clients.

[0] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1790