-inspections.registration.problems.abstract=Plugin component class must not be abstract
+inspections.registration.problems.abstract=Plugin component class is abstract

Hmm, I think the fact that the class is abstract is obvious to the user. The message should IMO state what it should not be.

-inspections.registration.problems.ctor.not.public=Action class constructor should be public
+inspections.registration.problems.ctor.not.public=Action class must have public constructor

I somehow agree with the "should" -> "must" change, but "must have a public constructor" somehow implies the class doesn't have one at all. Since the error applies to the ctor itself I think this doesn't fit that well.

In general I'd prefer the more defensive "should" over "must", and a - very non-scientific - check in the IG messages came out 38:11 for "should". Are there any other opinions on this?

-inspections.registration.problems.component.incompatible.interface=Component class is not assignable to its interface-class ''{0}''
+inspections.registration.problems.component.incompatible.interface=Component class must extend its interface-class ''{0}''

AFAIK, extending the interface class is not a hard requirement. One could use "java.lang.String" as interface class and only get a ClassCastException during runtime when calling getComponent(String.class) because of the generic method signature.

-inspections.registration.problems.component.duplicate.interface=Interface class is already used
+inspections.registration.problems.component.duplicate.interface=Duplicate components with interface class

What about "Multiple components with the same interface-class [are not allowed]"?

I also think quick fixes should be provided to create application-component in plugin.xml, etc. I don't have a patch to add those.

Do you mean a "Create Class" quickfix? Unfortunately I haven't seen an OpenAPI way to let the user choose the source path where to create the class in. I'm not sure if either just handling the standard case with one source-path or even replicating that UI makes much sense.

#2: okay, I think "Action class constructor must be public" is best then
I think should is confusing. The word "should" implies a gentle suggestion, but it's shown as a red error mark (and is in fact an error). The conflict between those concepts bothers me. I imagine a user could see "should" and not know why it was being suggested, but would see "must" and understand that it's a rule.

#3: If it shows as a warning, I think it should be changed to "should" and the inspection description should be good and easy to understand. If it shows as an error, I stick with my answer.

#4: I like yours best

#5: There are a few inspections which have obvious quickfixes which would not be difficult to implement, like "class does not implement ApplicationComponent" should add the implements entry.

By the way, is the intellij CVS repository kept current? I saw it was a lot of old plugins. I would probably commit more changes if I could simply update from cvs, so I didn't have to go through hassle of deleting old srcs from xx project folder, finding idea-install-path/plugins/xx/src/src_xx.zip, and unpacking it over my project folder.

There are also two new QuickFixes: "Extend/Implement class/interface" and "Create no-argument constructor".

The current sources are not in CVS but in SVN and I think you should contact Maxim or Dmitry for the details.