Even if this was a good idea - and I'm not saying it isn't - I don't see how it would ever end up on the product roadmap.
Let's explore why:
Staffing:
Kemper would be a small team of engineers. I'm guessing under a dozen. Probably less than half of that.
Prioritization of work in a development shop - especially one as specialized as this one - is of utmost importance.
Onboarding new staff is expensive - even more so when the engineer doesn't work out.
So the development overhead for a device like this is high. Cleaning up the code and documenting the spec would be an expensive task to undertake.
Competition:
As a developer, if I had the ethernet spec for the remote (I'm too lazy to sniff it), I'd be building my own remote. Probably with more features (Blackjack an Hookers). As an entrepreneur, I'd want to sell it. Why would Kemper want to introduce competition where there is none?
Test coherence:
Whenever a Kemper's developers merge to their repo, it's probable that a suite of unit tests fires to ensure all of the functionality that's present works as expected. It's much easier to do this if you control communication end - to - end. As soon as you introduce a third party component - such as an ethernet plugin or third party device - this becomes significantly more difficult. I'd hate to have to write the unit tests for this.
Product Roadmap:
What would we rather have the engineers work on - documenting (and subsequently enhancing) a feature 0.1% of the user base would take advantage of... or work on new effects and editing functionality that 90% of the user base would use?
I have no inside knowledge, just well versed in the realities of a continuous development cycle.