Thanks to everyone for the useful feedback. Some additional info and comments:
I'm well aware that this is a hard problem and that just calling nmcli is not an adequate solution. I was asking whether the problem has already been solved in a Debian-canonical way, since there are lots of other problems of this sort which do have such canonical solutions. Judging from the responses, it appears that the answer to that question is no.
Regarding what I'm trying to accomplish, as part of the revamp of apt-listchanges I need to rebuild the database that apt-listchanges uses to determine which changelog and NEWS entries it has already shown to the user. This can mostly be done from files installed on the local machine, but not for packages which don't ship a changelog.Debian file and instead expect the user to fetch it over the network with "apt changelog". Ideally I would be able to run a script in the background which gradually fetches these and adds them to apt-listchanges's database.
Ideally I would be able to simply attempt to fetch the each required changelog over the network and distinguish between "The fetch failed because there is no network changelog for this package" and "The fetch failed because it's not accessible over the network right now", but I can't make that distinction because neither apt nor python3-apt informs the user about what went wrong in any way that the caller can use reliably.
I've come up with a different workaround for this edge case which will do the right thing most of the time, but there are still going to be a few cases where, because I can't populate the database in advance, when the user goes to update a package they're going to end up getting shown the entire network changelog rather than just the new entries, because apt-listchanges can't reliably determine which entries they've already seen.
jik