The default InferenceEngine will create an anonymous type when is
sees a Object Literal.
Assuming that you have override handleFunctionCall() in you
inferengine to process the "qx.Class.define", in that code
you would "drill down" to that object initializer and call
"traverse()" in its field initializers, thus bypassing the default
handling of visit(IObjectInitializer).
The handleFunctionCall() should return false, so the InferEngine
does not visit the children of the function call .

I've tried this now. Unsuccessful, so far.

I made certain that visit(IObjectLiteral) in my inferencer is not
called. While debugging, I even throw Exceptions in the overridden
method, to be sure that the call doesn't pass there unnoticed. But
still the original problem exists: The inner object literal has an own
anonymous type.

I went into debugging to see where it is created:
The anonymous InferredType object that is passed to my
QooxdooInferEngine is not created by the QooxdooInferEngine. It is
created by another instance of InferEngine (itself, no subclass). So I
never get the chance to do something regarding the type creation for
ObjectLiterals.

However, it seemed awkward to me why I should reimplement the
ASTVisitor aspect of the InferEngine anyway. Having an anonymous type
as a placeholder during the type gathering is ok for me, and not
uncommon from what I know about type inferencing in other languages. I
just want to be able to tell it that it is the same type as "that one".
I didn't find anything in InferredType that suggests this
functionality. So I set the superclass of the anonymous type to the
known class. This works now for the functionality I intended right
now, but is not formally correct and will come back and bite me as
soon as I introduce visibility validation.

Do you think it would be reasonable to introduce a field in
InferredType that allows me to say what it actually is? It would be
close to the referenceClass, only not for array members but for "this"
type.