I get the impression that, by context, the implication is not that p2p is 'seamless', rather that it hasn't been changed for Odyssey exclusively...
Yes - I get the impression that they mean it won't be flipping between P2P and C/S depending on what you're doing.
(Which would have to be the case, when "what you're doing" could continuously go between flying and walking over a scale of several hundred kilometres with a chain of people all having visibility of the next person in the chain)
In short - support Systems or Events with heavy traffic (Hotspots) with Client/Server and increased/more stable Instances - while all normal random/low-traffic encounters remain P2P, where it is generally sufficient.
That'd hide the P2P limitations alot while requiring only a fairly low amount of effort in terms of Server support, as the vast bulk of Instancing would still remain dirt cheap P2P.
The tricky bit would be reliably determining that an instance was busy enough to be worth having a server host it (in practice, host the NPC actions and environment) and then have that start up and take over.
Having two slightly different network protocols each with their own set of bugs and quirks might also be interesting...
I'm not a network expert, but could someone explain how a connection involving three computers and two network paths (player <--> server <--> player) is going to be an improvement over a connection involving two computers and one network path (player <--> player) ?
It depends what you value.
If you want full consistency of state, you have to run the simulation on the server, and just send display information to the players and receive commands back. This has the slight issue that by the time you press the key for the command, you're responding to the simulation state 50-100ms ago, and by the time your command gets back to the server the state will be another 50-100ms further on. Whether that's a problem or not depends very much on the type of game. Also, of course, it means running some potentially very expensive simulations for something like Elite Dangerous which uses the GPU to dynamically generate planetary surfaces.
The big advantage of P2P for Elite Dangerous, however, is not for that case, but for the far more common case of "there is one player in an instance", which is basically all of them because of how big the galaxy is. Then the trade off is (player <--> server) versus (player) and the one without any network connections at all [1] comes out way ahead.
[1] Beyond relatively infrequent and small telemetry synchronisations, of course. But you don't need a mid-bandwidth stream continually open both ways.
servers really aren't nearly expensive enough to justify not to.
In the general case, certainly. And if you're developing for the B2B market where six figure software purchases aren't abnormal, definitely not.
In the case of Elite Dangerous Horizons [2], simulation would probably require a few hundred quid of hardware per instance, which basically means a few hundred quid of hardware per concurrent player.
The client-server space games all have much more restricted play areas where the number of players per instance is generally much higher (and often guaranteed to be higher) so it works for them.
[2] Without planetary landings and the terrain generation requirements, it would be fine. But that wouldn't be popular.