I was looking into that last night.
I'm not really using Arch in a network application for the moment so I haven't been following up on how they do things, but there are a few things that intrigued me about the networkmanager, as I've had some weird issues with it myself.
It seems that nm has a few bugs that makes normally straightforward functionality a bit weird, so that it's better to go about them carefully, and to set up critical routing and internal DNS and DHCP settings by hand basically. It seems like these bugs have been going on for a while too.
The problem that I was having on SuSE and Fedora, basically comes down to the fact that nm does not report or interact with systemd like it should with respect to certain functionality. It's really odd though, because on Fedora for instance it looks like it works, but crosschecking the system logs reveals another story. On SuSE, it was quite obvious that for instance setting some parameters in Yast, did not change the same parameter in nm, so it was clear that there was a problem there. Because there is a difference between Yast and for instance firewall-config used by Fedora, I decided to install firewalld and firewall-config on an Ubuntu system instead of the ufw. Turned out I get the exact same problem there as in SuSE. So for instance, something that is really visible and easy to see, when I change a zone for an adapter in firewall-config on a system with nm, that zone - which is a firewalld/systemd thing - should then copy that setting and report back on the setting, because it is not set directly (like when you would set it manually), but through nm. What happened is that the setting was actually copied by nm, to show up in the GUI, but it was not implemented, even after full reboot (which is overkill because restarting the services, and restarting the connection should suffice). So that was sneaky lol. On Fedora, that exchange was not flawless either, but only after adding an extra layer of settings, e.g. manually configuring a firewalld service and implementing it as the only enabled service in a zone.
When I checked the bug reports, I found several bug reports that point in the same direction, but in different contexts. It seems like this has been going on for 5-6 months in different releases of the concerned packages.
Basically, I think that it might be a systemd problem. Some communication channel between services and applications seems to be broken or at least unreliable. I guess it just takes a while for the devs to trace the issue upstream and in the right package.
When you told me your containers configure a connection, like they should, but then that connection doesn't connect, I thought it might be caused by this problem. But I haven't found any reports of exactly that problem in Fedora, probably because Fedora is less affected by it, or at least less visibly affected by it.
In conclusion, probably the best way is to configure manually like you did. You could re-DHCP internally over the internal connector for comfort, but I wouldn't do that because overhead and more work to roll back after the bugs are fixed or nm is upgraded with a solution.
I don't have precise info on what's going on in your system of course, but it seems to me that maybe the issue could be related, as your containers are not copying the host's settings they should be copying.