(ab)using mopidy-mpd for use with serial controller

[arkadirenko]

I do some research in the last days, as I plan to upgrade an existing stereo radio with integrated mopidy, but I wish to keep the current control possibilities like display, rotation encoders and knobs for local usage.
The device will be used by parts of the family only remote, via mobil phone/tablet/notebook, but occasionally it should be possible, to control it with the builtin controls. The management of the device with all its controls is done with a small microcontroller, which should be connected via serial port to the embedded raspberry, hosting mopidy. When researching possibilities i figured out, that the lightweight mpd protocol is far better for this purpose, than the core mopidy JSON-RPC.
I further figured out, that serial control is already possible today, by configuring the mpd server to listen on an unix socket, instead of an tcp port. Doing so, this unix-socket can be connected to an serial port using socat.
Volume control and playing the next or last song from the playlist is already possible, without any single piece of code change in mopidy-mpd.

BUT: Now there is the problem with the display, limiting outputs to 4-7 lines, depending on the font used. That means, I need a kind of pagination for all outputs, which produce more than this line counts. So my current idea is, forking mopidy-mpd and adding some more commands to the protocol, extending all those commands, where a bigger output is possible.
My current idea is, prefixing those extended commands with an unique prefix to avoid conflicts with upcoming new mpd commands.
Let me give an example:
lsinfo /path/to/directory
currently provides information about all directories/tracks contained in that directory.
X-lsinfo /path/to/directory
would now report back only the number of results, while:
X-lsinfo /path/to/directory offset=10 count=5
would return 5 results of this directory, starting on offset 10.
My current idea is, that the first call (without offset and count) would cache the result from the underlying lsinfo, and upcomming calls with offset to the same path would be served from this cache.
A call to another extend command or with an different path would invalidate the cache.

Before I continue with my work, I wish to ask if there are others, who work on similar issues or if there is an interest here, to discuss possible solutions?

P.S. I asked a similar question in the mpd project, as my plan touches the mpd-protocol. Especially if the would suppurt some special prefix, like the "X-" in hhtp-Headers, that could be very valubale.
MusicPlayerDaemon/MPD#2014