AFAICS, almost all of what you mentioned can already be built with the current library and its APIs. The only thing that would be new is a GitHub adapter.
- The client, not the library determines storage locations
- Built-in caching is optional, a client can disable it and use filesystem APIs instead
- You can use
storeFileandgetFileto store and retrieve files in any format
Regarding the name, we already have remoteStorage for the protocol, and remoteStorage.js (emphasis on .js) for the core-maintained JavaScript client library (which also acts as the main reference/example client).
It’s interesting to think of it as a concept, in addition to being a protocol. However, couldn’t that make it a bit confusing when you then try to explain to someone that the protocol is different from the concept? For example, if we used the term “email” for things that are electronic messages, but not using the email protocols, would that be a good thing for both email and the wider public? 
Overall, I think you’re hinting at more than what you laid out here, and/or maybe I’m not understanding it correctly. If the use case isn’t really compatible with RS (the protocol) at all, then I guess just building a different library would make sense. But if it generally might work with an RS server, then I think extending the library for whatever your client is missing could be worth it.
To that end, Finishing up the TypeScript and Mocha porting will make extending the library much easier and safer. However, I think there are some limits to the UX you can provide when you want both full filesystem navigation/storage and browser sync that deals with arbitrary changes on multiple devices. Really depends on the specific use case and details.