of course, because we don't even know about such an issue.
I filed a ticket way back when I first encountered the problem which there never was much feedback for. I've had my KPA since before the first RM was released so I guess that ticket should date sometime within the first month after RM was introduced. Then again more recently (ticket #KA00168926). I even received tweaked firmware for testing last June, but it unfortunately behaved just like before. I sent a description on how I reliably can reproduce the issue within an hour or two, since then I have only used RM briefly to pull a few rigs from the exchange. I submitted another question to the forum to check whether others with different types of computers have the same problems as I do with my Macbook and got confirmations from windows users too. On June 20th I got a follow-up mail with request for further logs which were promptly submitted, but nothing since. I do occasionally test some beta software, but only when I do have the time. Music is a hobby, and I prioritise practise and gigging. I make my living as a software/network engineer, but have no wish to run a software lab in my spare time. I do follow up when I get direct questions about KPA stuff, but mostly I just want to turn it on, play and switch off.
Don't get me wrong. I love my KPA, and even RM when it is used interactively to organise stuff and pull info from the exchange. It is only in a setting where RM may be sitting more or less idle for longer periods of time that the problem occur (recording/rehearsal). Still, it should not be necessary to always have to take care to disconnect the USB-cable from the KPA as soon as you're done with whatever you had to do in RM. It is so annoying during recording or rehearsal when the remote becomes unresponsive and goes into its boot-loop while the KPA gets stuck while playing. Granted, the unit normally keeps on making sound for the rest of the song, but all internal (knobs/buttons) and external controls (switches/exp-pedals) are non-functional until RM is disconnected or the KPA rebooted.
My worry for the editor is that it will be based on the same USB-communications as RM that I'm quite certain is the source of the problem. The KPA can not protect itself from connected gear/software that deliberately abuse functions offered by the KPA, but a malfunction/anomaly in any piece of gear attached to the KPA should not be allowed to affect its function, performance or reliability. If this problem boils down to an unresponsive USB-peer it is still a failure on the KPAs part. Any attempt to send or receive information on the USB-interface must be required to complete within a defined number of milliseconds. If not, then the operation must be aborted.