Not a lawyer, but the challenge I see with AGPL is that it leaves room for ambiguous interpretation. My reading of it says (paraphrasing) "if you combine AGPL software with your program and that program interacts with others over the network, you must provide the source". Web applications today are often composed of dozens of services and very few interact directly with the end user. Putting a reverse proxy in front of an AGPL app certainly violates the spirit of the license. When using an AGPL database, you might argue that the end-user is "interacting" with it, but I'm not sure. There are also plenty of other use cases where a network service could do something auxiliary to the user's requests.
In the past MongoDB has argued that using their AGPL database without providing source code is fine, Neo4j has argued the opposite. As strictly interpreted it seems like as long as you don't expose the AGPL app to end users you're not in violation. Maybe the license authors intended this, maybe they intended "if you use an AGPL application that in any way affects an end user's interaction, you must provide the source to that end user."
The action that subjects you to the remote network interaction restriction at the heart of the AGPL is "modifying" the covered work.
Modification is defined exactly the same in the AGPL as in the GPL. I don't think putting a reverse proxy in front of an AGPL app means much of anything in terms of either the letter or the spirit of the license.
Mongo's separation of Apache-licensed drivers from the server is about making it so that applications don't have to link to the AGPL'd server code, thereby avoiding "modifying" it. Without a modification, the network interaction section isn't triggered at all.
The "work" in this case would be the modified AGPL service. Using a reverse proxy, the "end user" would be the person running the reverse proxy, so you would owe source modification code to yourself, but nobody else.
There's a possibility that courts would interpret the remote interaction clause very narrowly as you suggest, allowing people to sidestep the teeth of the license easily. I think that possibility is fairly small, but you never know for sure of course.
Still, my main point was that the route taken by Mongo is intended to remove this kind of uncertainty: normal applications using it don't modify or include any AGPL code, so the question of just how far "remote interaction" goes never comes up.
The real question is, why FSF isn't stepping up and resolving this issue once and for good?
They must've heard about the problem. Why won't they make a statement about intended reading of AGPLv3 and publish AGPLv4 that has improved wording that avoids any possible ambiguities?
They can say what they intended to mean, and while that won't become a part of the license, a court may consider that. Especially if this would get widespread as "not tested but meant as a canon interpretation" common knowledge.
To put it in other words, clarifying won't hurt, even if it could have no real effect.
But, yeah, the real way to fix is AGPLv4. And FSF surely can do this.
In the past MongoDB has argued that using their AGPL database without providing source code is fine, Neo4j has argued the opposite. As strictly interpreted it seems like as long as you don't expose the AGPL app to end users you're not in violation. Maybe the license authors intended this, maybe they intended "if you use an AGPL application that in any way affects an end user's interaction, you must provide the source to that end user."