Hi @stevebaer and @clement,
Great to see the compiler is finally getting an update. Looking at your discussion I can only second all of Clement’s feedback as we are doing it currently in quite similar way, running into similar limitations and needs. Steve - allowing transparent commands will be great - is that going to be a switch per-command (like Hidden for example currently) or a default state for each compiled version? First would be better.
I also use RHI same way Clement describes - adding rhp and bunch of files (html, images, etc), zip and rename to RHI to create the package. Never used Yak - if this is better option that you would recommend and achievable to use by non-hardcore programmers definitely will need to look into it. If it has a way to keep the plugins better organized or automatic update downloads that would be great.
Telling compiler which Rhino version it should install the plugin for will be great, and also maybe adding the SR detection (now we can do it from the code but will be cleaner from the compiler).
As for password-protection - just that would not really cut it for my use, as nothing stops potential user that gets the password to share it freely with anyone else, so that would not be anything I would use.
That itself is probably worth a separate topic or non-public conversation, but unless McNeel could come up with a system that allows for easy protection, licensing and distribution of scripts (kind of like Apple Store apps) that would make it secure and straight-forward for scripters to share and sell their tools, it is quite challenging to do it in a convenient way currently. Since Rhino 6 and online zoo licensing change, we lost the ability to tie the script license to Rhino copy, as the Rhino Serial Number can no longer be easily obtained via script as the method returns random key in case online zoo is used, which most users do these days. So the choice now is to tie the license to hardware, which is not that convenient if the user want to use it with the same copy of Rhino on multiple machines. So I would need a scripted way to identify the user by some unique user ID that would replace the lost ability to do so by Rhino Serial Number. I have been discussing this with @aj1 in the past but to my knowledge this never got exposed. So I vote “no” or redundant for just rhp password protection, but why not if others find it useful.
Another somewhat related limitation that I tie into this conversation is the (bug?) pertaining to running python scripts inside Rhino commands. They work fine inside commands if compiled into a plugin, which is ultimately the goal, but, unlike RhinoScripts they will not from a button, which is a good way of testing them and not having to compile each time. I have reported it before and its here: https://mcneel.myjetbrains.com/youtrack/issue/RH-56354 but slated for Future… If this could be fixed it would certainly help with my development process and testing.
Lastly, I can certainly relate to this one Steve… 
Wishing you both health and a good mix of productivity and taking it easy, whatever it means…
–jarek