What I meant by compatibility was the content of the output - if someone today uses jackson1 is it possible the JSON output might be (subtly) different with jackson2 - such that it might cause problems with the consuming app? Perhaps a remote chance, but as long we have a way to force the use of J1 when both is on the classpath, we are ok.

1. I would call the abstraction JsonObjectMapper and leave the attribute as object-mapper.
2. Yes
3. I don't think so - can be the new abstraction, or a reference to a J1 (for backwards compat - which will be derprecated and removed in 3.1).
4. They should probably use the abstraction (in case we ever implement gson versions).
5. Not sure why you mention that one here.