Thanks for sharing some good solutions. Of course, tricks/workarounds often rely on finding places where JR failed to block an action that is in other places is prevented. The trouble with any workaround is, JR might "fix" their oversight and prevent the workaround. Climbing on my soapbox...
As is often mentioned, there are several areas where fields are fully or partially locked, where views are restricted, etc. (I keep wishing the Rating "stars" and Image File fields would be unlocked, for instance). Another example is the forced prevention of using a saved view as a saved playlist and vice versa. The saved files can be hacked, but that seems to prove the difference is trivial. So why make this very difficult for users? Other parts of MC can be hacked (registry, certain text-type config files), but it's undocumented and subject to change.
I wish JR would unlock all the settings, actions and options.
I have no doubt that JR's intentions are good, and that most MC restrictions are "for the user's own good". JR is trying to provide a stable product environment. But there are many levels of users, and already lots that can be configured that can mess up MC, so the reasons for the current restrictions are unclear. If there's a fear of breaking something, is it really a universal risk, or just an attempt to protect users from themselves? I wish JR would explain...
But could there be a compromise? Most database systems limit users, but also provide an admin and/or a bare-metal mode. Even Microsoft Windows allows a deep level of diddling for those who need it. How about giving MC a super-user mode or secret menu or alternate startup flag mode that would let all this be controlled? Even then, show strong messages about the "risks" ("Warning: Changing these settings could reduce or prevent compatibility with other products...") but don't block true power users from total configuration and customization. Why not?