My incoherent remark of last night can be clarified somewhat this a.m.:

Presently, creating a new class using the prototype

	#subclass:
	instanceVariableNames:
	classVariableNames:
	poolDictionaries:
	category:

message in the browser is apparently executed "in" the 
SmalltalkEnvironment, hence, to create a subclass of a toplevel 
subenvironment class, we must qualify:

	(FooEnv FooSuperClass) subclass: #NewClass . . . .

Not really an issue, albeit a bit inconvenient to type.  (We should 
consider how we want this to work -- life might be easier if the 
creation message were executed in the environment implied by the 
category).

Still cool, so far as that goes.  Now it gets ugly if we create a 
subclass of an object in the toplevel environment, say the usual:

	Object sublass: #NewClass . . .

here, big browser chokes big-time.  This is because the class 
construction stuff puts, by inference, NewClass in the same category 
as its superClass, in this case SmalltalkEnvironment, the superclass 
of Object.  That shouldn't be awful (although its unlikely that the 
user intended it to be a SmalltalkEnvironment object in the 
environment world), but here's what happens:

(1) the browser looks for the class, starting in the Environment 
*IMPLIED* by the class category, but looks for it using:

	envt at: name

This looks good, but doesn't do what one might first think.  The 
present "compatibility hack" does a DOWNWARD search (so "Smalltalk 
at: #foo" behaves similarly in the new and old universes).  Thus, the 
lookup for the class fails, because it exists ABOVE, not below, the 
implied class.

I think this was simply a typo bug (I don't see where the browser 
would want to look downward to find a class name), in which case the 
world is set aright once more with the following:

Browser>>selectedClass
	"Answer the class that is currently selected. Answer nil if 
no selection
	exists."

	| name envt |
	(name _ self selectedClassName) ifNil: [^ nil].
	(envt _ self selectedEnvironment) ifNil: [^ nil].
	^ envt atOrAbove: name ifAbsent: [self notFoundError]

The fix (?) is in the last line, which replaces the "envt at: name" 
with an UPWARD search.  Or perhaps it raises deeper questions.  I 
leave that to the powers that be.