I don’t pretend to know if supporting realtime shared collaboration is worth the investment.
One approach would presumably be to split Scrivener into two pieces, client and server, as is done for most first person shooter games (Doom, Unreal, HalfLife, Halo, …) to support realtime multiplayer. For traditional standalone use, both pieces would reside and run on the same machine and the client/server nature would not be obvious (same as standalone singleplayer play of FPS games). For collaborative use, the server component would probably usually run on one of the collaborator’s machines… though it could presumably be run elsewhere on more of a dedicated server. Such might also enable providing full robust Scrivener capability via “thin” clients on lower end/mobile devices not up to running the whole thing (although what such devices can handle is growing rapidly by leaps and bounds).
By now, such client/server architecture design and use is widespread enough (he said blithely) and open source code versions of some exist that reference materials and programmers experienced with such exist such that might be able to draw on the game and other industries in order to build such.
Less ambitiously, there might be some limited collaboration that could be supported… simple lock/unlock checkout/checkin of individual files and/or folders… with resulting global changes being deferred till later…? But from what I’ve seen, primarily from providing customer support for simple non-client/server Microsoft Access database applications, attempting to support multiuser with anything less than full blown client/server results in really sluggish performance and integrity issues.