still noone interested?

rsync is a synchronisation protocol, not a file and folder navigation one. I don't see how what you ask is even possible.

I'm not 100% confident, but:
GoogleDrive and MTP are also not-so-fs-ish protocols, but gvfs backends successfully emulate file and folder navigation for those.
rsync is quite straightforward about files and folder (in favor of e.g. GDrive object storage) and shouldn't be a problem getting and reflecting those to gvfs.

I do not also understand how that should work and why it could be useful. Can you please specify some use cases? I also doubt about that rsync protocol allows necessary API, but maybe I am wrong...

I compared RSync to MTP and GDrive from the implementation perspective.
But its use-cases are closer to FTP and WebDav protocols: RSync is used for internet file resources access.

Example 1: together with HTTP and FTP, a public internet storage may provide rsync access to files:
$ rsync -v ftp.altlinux.org::ALTLinux/

Example 2: many NAS systems also provide CIFS, NFS, FTP and RSync

Example 3: using rsync+ssh gives secure access that FTP can never provide. Used in some organizations.

Indeed, Google Drive and MTP are a bit special, but still filesystem/transfer protocols. However, rsync is designed to be synchronization protocol, which means that it expects that you have physically the same file trees on both sides, on a server, and on a client, but this is not how GIO works. rsync protocol is provided in all your use cases for synchronization (e.g. for shared documents in a corporation, shared conference files, or for backup), however, there are always other ways to access those files (like FTP, SSH, HTTP, SMB, NFS...). rsync can be faster, but only for synchronization, which is irrelevant for GIO. So I don't see the need for such backend. 

On top of that, I see at least two other problems. The protocol is not probably documented and there isn't probably any public library. We can probably just parse output and input of the rsync binary as we do in other backends unfortunately, but this is pretty fragile and the rsync binary provides really limited functionality to us.

The very last thing is that GVfs lacks manpower. So if you willing to write such backend and it will provide reasonable functionality, we can merge it, but do not expect much activity from our side in this area, I am sorry.

Yes, rsync is a sync protocol but that means (to me) the superset of filesystem/transfer use. One use is syncing two trees (you're absolutely right) and another is browsing a remote tree (if DEST is omitted).
I don't agree that (shared documents in a corporation) is a sync usecase but that's quite special and narrow case to my regret. IMHO I consider rsync as a transport just like HTTP became a transport for many different uses.
Regarding the problems you highlighted: I hoped on the librsync (https://github.com/librsync/librsync) but I was crucially wrong: it is the very different and incompatible library. Shelling the rsync binary is no choice of course.

The last shows the idea's too far from reality.

I am very sorry that I wasted your time without proper understanding of the question.
I hope I wasn't too annoying.

No problem. Thanks for understanding.