@Septopus, I think I understand your dilemma.  You kinda lost me at  "the system will be retrospectively authoritative wherever possible"   but after reading enough of your words I think I get the problem you're talking about.  The only thing I can offer is what I'm doing but it comes with limitations that may not suite you 100% and by all means you may have already thought of something similar.

I'm planning on running the simulation as far into the future as possible, basically I plan on processing as much of the NPC activitiy as I can.  For instance the way I've got my NPC movement worked out is they all move on lines, this is great because all I need to store for NPC movement are sets of lines.  So All movement about the world has been simplified.  The simulation server all ready knows which line comes next in the line set.  I plan on doing the same with NPC logic too.  The server will have all the future actions of NPC's stored, then tick by tick each server than says 'This is now what is happening'.  The server doesn't send the clients updates about what is happening now but what will happen.  The client just basically plays the animation for you.   The idea is the client and server process at double speed but play a normal speed.

Then, any time a player modifies the actions of a NPC, the server devotes real-time resources to quickly update the effects it may have on the rest of the simulation and NPC and, in theory, will replace actions within the store of action sets.
For my project, because of the type of game I'm making, the action isn't going to happen within milliseconds, like a FPS, so I can get away with not having two human players seeing the exact same thing within a very small time-frame.  If there is a bit of a difference I think It should be kosher, so long as the bigger simulation is preserved.

What are your thoughts?

haha, yeah, that's where I keep losing everybody..

I really like your methodology here, and I may borrow some concepts for my AI as well.  I wish I could say that any aspect of my game was half as well thought out as yours.  lol.

Here's the main difference in what I'm doing vs almost everybody else here it seems. I think anyhow.

I'm doing things completely backwards. 

And it's intentional.  haha  I'm creating what I've been calling a semi-authoritative or a retrospectively authoritative server architecture. 

My servers do not run the simulation that the players are seeing.  They coordinate the moving parts, and broadcast the movements and actions of network players and network objects based on some anti-cheating math I've yet to figure out.  They send rewards and corrections.  They'll also be running simulation(s) of their own, that they will be injecting into the client's gaming environments and interacting with/making decisions based on those outcomes.

All of their authority is in what data they filter in and what data they send back.  Everything runs in real time.  I keep a synchronized clock which fills the role that a frame number would in a fully authoritative server controlled simulation.  I guess my model might not even be considered "authoritative" from the perspective of most game designers. 

A specific example is how my multi-player code works.  A player character moves within the game and broadcasts it's actual position data as it does so.  So this would seem to be Client Authoritative... But, there will be authoritative controls that will limit the player's ability to do things like move faster than they should, or jump higher than they should, etc..  The server can interject by reflecting back corrected position/velocity data whenever it deems necessary.  The client should then take measures to reconcile the anomaly within a calculable amount of time.  So, as you can see, my servers are authoritative, just not in the traditional sense.  More, retroactive, on a millisecond scale. 

If it takes a few extra milliseconds for the loot drop to happen, it's not a big deal, if the entire simulation lags because of a crappy connection, that's a lost player.  Using this methodology I can allow the player simulation to run at whatever speed it wants, and the server simulations as well.  Network player movements don't need to be less than a half a meter of accuracy and the broadcast frequency can be pretty crappy and you'll still get a decent multiplayer effect.  All I have to keep track of is what's happening right this very second, and have a short-term historical record that I can scan to verify that correlating data sent from multiple clients isn't too disagreeable, and when it is, pick the culprit and issue corrections before the simulations become noticeably out of sync.

Starting to ramble.. haha

Maybe some of that makes sense?

Another way to put it I guess is that my "game" is actually a System that houses many different simulations that interact with each other in real time.