Looks acceptable but there's a cyclic dependency between the two models in com.mbeddr.mpsutil.intentions.runtime. It's only models, not modules, so it's not a big deal but still let's keep it one-way unless absolutely necessary.

As an idea for future customizations since I see the 'pass map and modify it' pattern taking hold: to take it a step further, instead of passing a map, an even better API IMO would be to pass in a builder object that would have methods to build the map internally or maybe do something else in the future, but that allows to have multiple methods, e.g. as a convenience or when additional features are needed later.

void customizeIntentions(IntentionCustomizationsBuilder builder) {
  builder.customize(node-ptr/MyIntention/, new IntentionCustomization {
    @Override
    public string getDescription(node<> node, EditorContext editorContext, { ⇒ string } originalImpl) {
      "my customized description";
    }
  });

  // later if we e.g. find that users often only customize descriptions and only use hard-coded constants,
  // we could introduce a simpler way without breaking user code:
  builder.modifyDescription(node-ptr/MyIntention/, "my customized description");
}

Looks acceptable but there's a cyclic dependency between the two models in com.mbeddr.mpsutil.intentions.runtime

The extension point needs to be in the plugin model and is referenced by the runtime. The only way around this would be to move all classes to the plugin.

All other things I fixed.