The root problem is that NMSettingIP4Config has always treated a metric of '0' as default, meaning that it should apply the device priority as the metric.

Unfortunately with assumed devices, their NMSettingIP4Config gets generated from the device IP configuration, and often the metric is 0 because that's what the external program that created the route set the metric to.

So when nm-device.c::ip4_config_merge_and_apply() calls nm_ip4_config_merge_setting(), 'composite' will already have the right routes + metrics because they were added to 'composite' when merging priv->ext_ip4_config.  But the NMSettingIP4Config *also* has the same routes (and with a metric of 0 too) because external routes are added to the connection.

nm_ip4_config_merge_setting() overwrites anything that's already in the IP4Config on purpose, assuming that user-specified routes should override whatever existed on the system because the user specified those routes themselves. Unfortunately we (a) lost the fact that these aren't actually user-provided routes and (b) treat 0 as 'device priority' when merging a setting.

Maybe if the connection is generated/assumed we don't merge the NMSettingIP4Config at all, since that would be redundant?  If the user changes anything we already reset the 'generated' flag on the NMConnection so that we know it's been changed.