"Lex Spoon" <lex at cc.gatech.edu> gives the following example.
	Suppose I have the following changesets in my image:
	
		URL
		HTML-Tokenizer
		HTML-Parser
		HTML-Formatter
	
	[Current change set is HTML-Parser.
	 Bug found, implementors-of+, blue message list -->Url>>fragment]

Yes, the "changeset associated with browser" proposal does NOT fix all
known problems.  With this kind of situation, you are no better off that
with the current approach.  BUT YOU ARE ALSO NO *WORSE* OFF.

The fundamental problem is things going to the _wrong_ changeset without
you noticing, especially when you are a beginner.  (I have 13 of them
right now.  14 if you count the staff member sitting in.)
	
	It seems like the system could easily guess which changeset to put
	something in, most of the time.  The big question, it seems, is whether
	there is a scheme that's so complicated to configure that it beats the
	point....
	
Here's another idea.
When a browser is about to accept a change,
 IF (the last change to this class was more than 12 hours ago)
 OR (a new changeset has been created since the last change to this class)
 THEN *ask* what changeset to use for this class
 OTHERWISE use the same changeset as last time.

Yes, I know this is only a half-baked idea, but I think the heat is
coming from the right direction.

	Changeset-per-browser doesn't really help here.  All my changesets and
	message windows and such will be assigned to the Parser changeset.  Even
	if I have a URL browser floating around, I would have to dig through
	that browser to find the right method again, and that's even more work
	than switching the active changeset.
	
I don't think it's more work than switching the active changeset TWICE,
though.  Because when you return to working on Html-Parser, that's just
what you have to do.

By the way, how _would_ my changeset-bound-to-browser proposal far?

Browser 1 (green browser) bound to Html-Parser.
Do implementors-of, get Browser 2 (blue implementors list) also bound
to Html-Parser.  Repeat several times.
Now in Browser N (blue) viewing Url>>fragment method, still bound
to Html-Parser change set.  The change set name is shown in the title
bar, so you can SEE that it is the wrong change set.
Single keystroke or some kind of mouse click brings up a menu
including "choose change set", select that, choose from list, done.

I completely fail to see how this is any harder than the current method
of choosing a change set, especialy as with this proposal you do it ONCE,
while with the current approach you have to KEEP changing the "global
within project" changeset as you move between browsers.