…like supporting multiple entries in our typemap,

Supporting multiple entries in the typemap sounds good, but isn't; for managed-to-java maps, there's no problem. Java-to-managed is the problem, and eventually you hit an "untyped" code path:

var list = new Java.Util.ArrayList(); // holds Java.Lang.Objects
using (var e = new SomeType()) {
    list.Add (e);
}
var o = list.Get (0);

What's the runtime type of o? This is where the Java-to-managed map comes in, and if SomeType happens to have a [Register] value shared by other types -- such as Android.Runtime.JavaList() & Java.Util.ArrayList (same [Register] value) -- then how do you choose which type to use?

Multiple Java-to-managed mappings doesn't help matters. A choice must eventually be made.

… or not emitting [Register] on our synthetic classes we create to allow access to Java interface constants.

I rather like this idea, and cannot remember why we wanted/needed [Register] on the BaseColumns type in the first place. Particularly when that type has an internal constructor, and thus cannot be subclassed.

We should explore this option.

We should also accept this PR (#798).

Multiple Java-to-managed mappings doesn't help matters. A choice must eventually be made.

I was referring to generator's SymbolTable, not the typemap we bake into assemblies. You are correct that we eventually have to make a choice, but for this case we could choose one that is an interface rather than a class.

I was referring to generator's SymbolTable…

My mistake, I didn't realize that was the context.