Assuming all the networks are on independent subnets, the kernel’s routing tables should mostly send IP traffic in the right direction. For instance, if your LAN is on 192.168.0.0/24, Network A is 192.168.32.0/24, and Network B is 10.0.16.0/16, then on a machine directly connected to all the networks, packets will basically just go to the right place. However:

• If you want devices on your LAN to be able to reach those other networks without directly connecting, you’ll need to set up a routing table for those devices. That’s where an OpenWrt (or similar) device comes in.
• If the networks’ subnets overlap, it’ll be a rough time. Let’s say that Network C is on the same range as your LAN; now you can’t directly route to it because your computer doesn’t know which instance of 192.168.0.13 you actually wanted to connect to. There are ways around this, but they get more complicated. It’s better (if possible) to just have everyone pick non-overlapping subnets.
• This is just the IP layer. If you want to access services through a domain name, you’ll probably want a DNS server (e.g. dnsmasq) that forwards requests to the appropriate name servers for each network. If you have service names or auto-discovery through multicast DNS, you’ll need an mDNS reflector to forward the traffic across network boundaries.

Interestingly, IIRC, one of the major hormonal factors in irritability during the menstrual cycle is a relative spike in testosterone levels. (Non-expert, could be wrong, but heard this once.)

The coupling in PID 1 is a bit much. I actually quite like systemd-networkd for some use cases, though. It lets me declaratively manage the network interfaces on my headless servers in a way that’s very similar to how I’m managing the services. Sure, it’s coupled to systemd, but it’s mostly one-way coupling; if I want to use NetworkManager (which I do on my laptop), I can switch over, and nothing in the init system breaks.