There exist a number of successful gaming APIs that solve the higher-level probles. Google Play API, Apple Game Center, Parse, Gamedonia, Playstation Network, Xbox/Windows Live, ... Maybe you should look at those for inspiration on what developers actually expect/use?

There also exist a number of previous projects that try to solve bigger pieces of the puzzle, in various ways -- Photon, Smartfox, TNL, Darkstar, etc. These almost entirely end up also integrating the server side, because the implementation of the higher-order functions in the API end up being dictated by actual needs on the server side. (TNL is an exception -- you can actually use it stand-alone on both client and server, just like you suggest.)

I'd expect an integrated library to allow me to run the authentication on a different set of servers than the actual game.
High-level features include:

- Account management (create/update/verify/admin/hold/ban/permission levels)
- Authentication against accounts, returning a re-usable auth token with a lifetime
- Game host/server listing and discovery
- NAT punch-through introducer
- Player data persistence (skill/rating/score/whatever)
- Player matchmaking
- Game instance hosting
- Player game host join
- Verification of auth tokens
- Session management
- Maps/assets and game patching/updates
- Match start
- Game networking (messaging, RPC, time management, sync)
- Match conclusion
- Highscore tables
- Friend lists
- Player groups (guilds/clans/circles/whatever)
- Friend online status
- Cross-game-instance friend messaging

From an API point of view, I'd expec the game to let me describe my own packet structure, with varying transport and reliability concerns. I'd like the networking API to be event driven -- I poll the network, it generates some number of "events" which could be "RPC incoming" or "player update" or "player requests authentication" or whatever. The hosting application then responds to events in one way or another asynchronously from the generation of the event. If verifying an account requires a three-second round-trip to a web service, then the game server should keep pumping the network/loop and receving more events, even though the result of the "player requests auth" event is currently outstanding.

I'd love to see it when you're done!

The kinds of physics update mechanisms you describe are very gameplay centric, and define the "network feel" of a game.
Each game does these differently. Solving those equates building a networked gameplay engine. This is why you can't find "standalone libraries" to do this, outside of the existing game engines.

Btw, in the distant past, there were some ideas considered by virtual world vendors relating to a standardized virtual world entity protocol.
This would let various games talk to each other. The proposals from that effort might be helpful to consider what it would look like to try to abstract entity updates from actual gameplay:
http://www.ietf.org/staging/draft-ietf-mmox-less-protocol-00.txt

Edit: Also:

-callbacks (rpc?) are provided to the lib that operate on the game objects

I like events for this. (Could be as simple as a struct with a type field and a union)
The reason is that the application might not be able to immediately resolve whatever the result of the particular callback is.
Trying to force the application to be synchronous will seem convenient in the beginning, and end up as a huge pain in the end.

Formalize a higher level slowdown/choke throttling operations

The higher level App should need to be able to be signaled to throttle the game action (various ways) to handle the (hopefully temporary) situation gracefully as possible (instead of the simulation just packing in more packet traffic ontop of the already choked network traffic)

You can build NAT punch-through on top of Enet. No re-write needed.

The trick with match end is that groups of players may want to stay together while "traveling to" or "choosing" a "next map."
For games with zoning (MMOs, larger campaigns, co-op, etc) that's also an important consideration.

As long as the callback doesn't have to immediately return a result to the library (such as "user is authenticated") but instead the program returns the result somewhere asynchronously, callbacks to deliver events isn't a problem.

Static versus dynamic RPC: I'm not sure this matters -- the only difference is "which bit of code does the registration?"
It's important to remember that both sides of the connection need to agree on what the RPC is named and meant to do, which limits exactly how crazy this can get :-)
A thing you might want to consider is the ability to "address" game objects. So, rather than introducing a global RPC function called "FireWeapon(id, directio)" you can introduce the function "Fire" on the weapon, and the RPC name/scope would then be registered on the object class, rather than globally. For some things, this is great (especially if you want to support modding that adds new classes of objects.) For others, it's unnecessarily complications.

Object descriptions generally have to be encoded in code before the program starts. Trying to add a new type of object that wasn't avaiable on game start (or at least level start) is something that large virtual worlds have to solve, but which FPS games generally don't benefit from.
If you want packets to be efficient, you'll want a binary protocol on the wire. You could use a JSON file (or any other language/format/IDL) to describe what the objects/packets are, and then use a code generator to build the C++, LUA, and what other languages you want, to read/write the packets. Then plug in the game code on top (not inside the generated files!)