I think you basically decribe what remoteStorage.js data modules are intended for.
From my point of view, the main issue so far wasn’t so much the technical possibility of sharing the modules between apps (which exists and has been done for a few, e.g. bookmarks). But I think it’s a problem that there just aren’t many existing modules, and usually new app developers don’t want to start new shared modules, when they’re only just getting started with remoteStorage to begin with.
What you call “protocol”, I would perhaps call “data model”. What we’re talking about is the documents’ JSON-LD vocabulary (which we describe using JSON Schema in rs.js data modules), combined with the data ontology, i.e. folder and document structure, links between documents (not supported in current modules, but likely necessary), and the naming of them all (including category names).
So, based on what you wrote, on what we currently have, and on what was discussed in the community thus far, personally, I would imagine that we need some kind of registry for the data models, which (ideally) would be generic enough so that it could even be used with other protocols (e.g. SOLID), or even with custom APIs (like e.g. ownCloud/Nextcloud). And perhaps we could/should make it easier to create your own models/modules, when you’re only starting out with RS, using things like best practices documentation, tooling, etc.
However, I’m not sure it’s desirable to make it too generic from the get-go, because you wouldn’t want to standardize before experimentation and usage, in my opinion. The first step I would propose is to separate the schemas from the code of the data modules, and to think about how we can (internally) describe and standardize things like folder structure and naming, as well as advanced use cases like linking (both schemas and documents), as well as search indexes and such.
I would be very interested in what others are thinking about this topic. Let’s discuss brainstorm!