I have pretty few experience with multiplayer networking, but maybe you can give me 2 examples of multiplayer games, which will be controversial to each other in terms of networking? (I'm talking not about existing games, rather about 2 design examples)

Compare in each case what the total number of players are, what the numbers are in your immediate visible neighbourhood, compare how far you can see and how you can interact, and compare how responsive the game must be. Also compare how "realtime" each of these games really are (hint: time does not always pass at the same pace in each of the forementioned).

To give an example why your design in any of these may differ greatly: Half a second of lag isn't great in a strategy or "build a town" game, but it's acceptable. In a "typical" MMO, you'll have complaints on your user forums or people leaving, and in a shooter game, you will receive massive shit storms and death threats. In a round-based game (which includes pretty much every board/card game), half a second isn't even noticeable.

Compare...

To give an example why your design in any of these may differ greatly: Half a second of lag isn't great in a strategy or "build a town" game, but it's acceptable. In a "typical" MMO, you'll have complaints on your user forums or people leaving, and in a shooter game, you will receive massive shit storms and death threats. In a round-based game (which includes pretty much every board/card game), half a second isn't even noticeable.

"Slow" protocols are exactly "acceptable" for some games, just because they are easier for development.

Faster systems aren't "the same, but faster". They usually have limits on what can be serialised and how much, to keep message sizes down. They may place requirements on your game to store several copies of state, to be able to rewind and replay from previous positions, or to be able to extrapolate from them. They may expect you to be sending a constant stream of redundant updates so that if some are dropped, it doesn't matter. None of that makes sense for a slow turn-based game.

how to handle interpolation or extrapolation

They usually have limits on what can be serialised and how much, to keep message sizes down.

But we have very complex fast games which have to send lot of data and they are working pretty good – so, it's possible. Of course, such protocol should not be used to, say, sending a media files, but we're talking not about some sort of The Ultimate Protocol, we're talking about pretty narrow use cases – multiplayer game client-server sync, basically.

We can't take slow protocol for a fast-paced game, but we can easily take fast protocol for a slow game.

You do realize that a "slow" protocol is exactly as fast as a "fast" protocol? (Well, that's not true as it stands, but read on!)

A "fast" protocol is primarily not fast because it is any faster. This is, by the way, not limited to user protocols, it is a common misconception about TCP and UDP as well. TCP is exactly as fast as UDP. Except when reordering or packet loss happens.

A "fast" protocol is fast because in presence of packet loss it simply moves on and ignores the lost packet rather than stalling. That, and of course a "fast" protocol is paying a lot more attention to squeeze out the last bit only sending the absolute minimum necessary, leaving anything redundant out -- because only so and so much will fit into a packet.

That's OK for e.g. a shooter where there are not many interesting things other than "this single opponent moves to xyz" and "shoots at you", or "subtract 1 from life points" happening, but they happen in rapid succession, and woe if you don't get them in time.

But in e.g. a "typical" MMORPG you may as well have to transmit information like "This guy at XYZ is wearing a holiday gift hat, and the premium Soul Reaper armor with the Burning Sword of Z'kaaah. Right now he changed clothes and did the 'obscene gesture' emote. The other 45 guys on the screen are wearing...".

Not all of this information has the same importance (for example "orc hits you with axe" is certainly higher priority than "guy 20 meters away changes hats"), and usually there is some rather hefty prioritization going on. While surely able to "afford some more", still a MMO has to pay attention to bandwidth. Just do the math and see what happens when you send out two kilobytes per second to a thousand users all day long. Over a month, that's 5 terabytes (not counting network headers, traffic in the other direction, or other stuff).

A "fast" protocol is fast because in presence of packet loss

And, in addition, "fast" games still need to check states and so on "to be sure" - so, they still have to use some kind of "slow" protocol sometimes. And all this could be a part of common protocol, which has stuff for very fast messaging, for "reliable" messaging and how both are related to each other.

Again: I still don't see any conflicts why we can't take a "fast" protocol (I mean, the one which used for a fast complex game) and use it for slow/simple game.

Sure, but what does it change? If it's fit for fast complex games, it will fit for slow games anyway.

Not necessarily, the design between using a "reliable, ordered" and "unreliable" service is an entirely different one.

And, in addition, "fast" games still need to check states and so on "to be sure" - so, they still have to use some kind of "slow" protocol sometimes. And all this could be a part of common protocol, which has stuff for very fast messaging, for "reliable" messaging and how both are related to each other.

Not necessarily, the design between using a "reliable, ordered" and "unreliable" service is an entirely different one.

Yeah, but we're talking about common protocol, not specific implementation. So, each specific game could decide if it's needed to use one or another part of the protocol or not.

Raknet has that

Raknet is specific implementation, not sure they have their protocol specs (please correct me if I'm wrong). Also, AFAIK, Raknet is not yet supported anymore.

Ok, I've give up until I'll learn all that stuff more closely to find specific arguments. But I'm still sure it's possible to design a more-less high-level common protocol for a multiplayer games...

Anyway, thanks everyone for discussion and patience :D