1. Enums. For each constant listed in the enum, there is one instance for the entire JVM. It has whatever fields and methods you declare on the enum. So, you are declaring a collection of named singletons which have a common contract.
2. Here's the modularity dilemma as I saw it. If we want to seriously support multiple IMSs, there is a lot of work to do. The comment at the top that we only support 'changes + 1' is there for a good reason given the code. So, I felt that I either had to tackle the big job of actually making it operate on and iterate over multiple systems, or I wanted to enforce the restriction. Now, I could scope the creation and use of the new object(s) to within the blocks for the individual IMSs, I realize, and leave things no worse off then they were. I'll do that.
3. If you prefer an interface, I think I'll rename the class from Abstract to Default, and add the interface. Unless you prefer the non-JIRA case to start out with no mappings, in which case I'd add the JIRA subclass.
Generally, I want to point out that this whole business is somewhat off to one side of the patch that started all this. All IMSes that I know are configurable. So, with or without this stuff, we still need to keep the original patch code that allows the user to configure their own mappings. I wonder if we should release what's currently checked in before continuing with any variation on this.