MPS plugins are specially configured solutions whose compiled code is loaded into the IDE and can be dynamically reloaded if modified. This supports live development: your code can be immediately tested in the current MPS instance, without having to start a separate MPS instance with your plugins.

MPS runs on top of the IDEA platform which also provides a plugin mechanism. Until recently, IDEA plugins were non-reloadable. If you were developing an IDEA plugin and wanted to see it in action, you had to start another instance of IDEA. If you wanted to add or remove plugins from the IDEA instance that you were working in, you had to restart it to apply changes.

Thus, the MPS plugin mechanism is distinct from the IDEA plugin mechanism. In particular, IDEA plugins are not loaded from MPS project libraries.

When you decide to create an RCP with your languages and MPS plugins, you define IDEA plugins in the build language, specifying which MPS modules they should contain. Your MPS plugins will always be a part of an IDEA plugin when packaged in an RCP, and will become non-reloadable (but your users are not supposed to be modifying these plugins anyway).

Why even talk about IDEA plugins in the context of MPS? IDEA plugins are more powerful. They are configured via an XML file (META-INF/plugin.xml) which lets you define extensions for extension points that are provided by the IDEA platform. For some of these, MPS provides DSLs and mechanisms that abstract over their underlying counterparts: this applies to actions, tool windows, and to a certain extent, preference pages.

For example, MPS plugins define actions and action groups, and these are dynamically registered with the IDEA action manager when the plugin gets loaded, and unregistered on unload.

In some cases, however, the abstractions provided by MPS fall short. For example, MPS provides no way to register an application-wide persistent component for storing configuration properties. (As an aside, MPS together with the mbeddr platform provide about three different languages that deal with preferences and their persistence, but each of them only covers about 80 % of what it should.)

When MPS abstractions are not enough, it may be necessary to resort to writing an IDEA plugin, with all the disadvantages that it brings. An example is the actionsfilter plugin of mbeddr. It uses application-wide configuration storage and has to be written as an IDEA plugin, but mbeddr itself is most often used as a project library. In the latter case actionsfilter does not get loaded and it becomes impossible to edit action profiles.

A workaround is to copy actionsfilter and its dependencies into your MPS plugins directory but this makes it impractical to use the exact versions that are specified in the project.

These difficulties only affect developers, however. Since at the build time every MPS plugin is wrapped in an IDEA plugin anyway, the end users only ever deal with non-reloadable IDEA plugins.

Avoid IDEA plugins if you can, but know that they are there for advanced use cases.