> Adding a new DeclarationType would work, but IIRC that flag enum is very near capacity already (there's only so many bits to offset in an Int32).

If hidden interfaces give us access to members we couldn't resolve before, then I'm all for it! Not giving it the ClassModule flag should effectively mitigate risks of regression, but Max would likely have deeper insights on that matter.

In my mind the decision hinges on what we're looking at - if having these types in the finder grants Rubberd

> First of all, the unexpected supertype names no longer make the resolver explode. It simply issues a warning and does not add the supertype.

Option 2 is out of the question. The entire point of the `TypeHierarchyPass` is to connect classes with their supertypes. Adding a new declaration here would either duplication in our state with partial information on each instance, provided we actually make the effort to generate the right declaration, or add a disfunctional stub.

Anyway, we really

> Adding a new type shouldn't be a problem because the `DeclarationType` is already a `long` and we are at 35th bit so we exceeded the 32nd bit a while ago. :-)

The hidden interface is the one that provides us with definitions of controls on a form. We would need to use that hidden interface to additionally determine whether a procedure declared on a form is an event handler.

However, from a user's POV, we want to show it in the toolbar as `[Form_Silly Name].Silly_TextBox`, rather than `[