If a plugin developer wishes to remove a module, they can instead deprecate it by adding "deprecated": true to the module’s JSON object. See .modules[].deprecated in the Manifest manual. For example, if you want to change a module’s functionality that would break its patch compatibility including changing knob scaling, removing a port, changing DSP behavior, etc., simply create a new module with a similar name but a different slug (e.g. MyModule2) and mark the old module as deprecated.
In a future version of Rack, deprecated modules will not be displayed in the Module Browser by default but can still be used when opening old patches. If viewing deprecated modules is enabled, the module description should suggest which new module to use instead.
VCV Library will indicate that a module is deprecated with a special tag or statement on the module page and thumbnail box.
The ability to deprecate modules will allow plugin developers to hide their shame move forward with development without worrying too much about maintaining patch compatibility, while users are able to archive their old patches without worrying about plugins making breaking changes to their modules.
Who will be the first plugin developer to deprecate a module? 
