This is being discussed with development, I just wanted to let you know we're not ignoring it. One proposed solution moving forward is to incorporate our own event trigger system - for example, when a reaction is provided, send a "reactionGiven" event that you can then work with. This allows you extendability without us needing to get hacky.
Once the core devs have given more insight, I'll update this so we're all on the same page.
We cannot allow encoded applications in the marketplace, I'm afraid. Setting aside the obvious security implications, we frankly don't want to deal with the refund requests, complaints and ill will when they can't get the app to work on their $20/yr. server - it's not worth it to us.
Our apps aren't encoded, even Nexus/Commerce as of IPS4. There's reasons for this -- they're a hassle from a support standpoint and they tend to annoy people in this industry. In this case, it just seems a bit strange to encode an API - I think I would take issue with having two products and then yet another third party product in between passing data that I'm unable to see.
Regarding the licensed URL requirement -- @DesignzShop; believe me, I'm aware of your request. I haven't had the time nor inclination (you're one of maybe 3 people insistent on this) to properly vet this. At a minimum, our terms and conditions would need to be updated and a disclaimer added to note that they are sharing this information with a third party not affiliated with IPS. I have no problem adding a field, but I'm not so sure about allowing it to be required.
Security bulletins will be handled differently in 4.0. We will also post them on the front-end (ONLY for admins, of course) as we often get complaints "I don't login to my admincp for days, weeks sometimes!" But I'll be sure we have a way to at least dismiss the bulletin once applied.