In another case, I wanted to have a GUI window operated by the main 
thread of a program (another simulation), and and have another window 
controlled by a secondary thread that would render the results of some 
heavy duty calculations as the results became available. For performance 
reasons I needed to have each window controlled by a different thread. I 
ended up scraping the GUI.
The standard way of doing that sort of thing is have a single "graphics"
thread that controls the one or many windows, and offload the heavy
calculations on different threads which signal the main thread to
redisplay. Again there's no need to have multiple threads control
GLUT/GL contexts.
Thats what I'm currently doing, and I can do that when I have one window, or a fixed number of windows. Needing to create and destroy windows complicates matters a lot.
Also if you could use multiple processes as someone else suggested.
I definitely could if portability was not a major concern. That would be more suited when graphics is the main concern of the application, which in my case, isn't.
So yes, it is desirable to have multiple windows controlled by a single 
process running multiple threads, even if the cases where this would be 
done are limited.
I'm not saying it wouldn't be nice to have that option. But I don't see
the "need" for it, nor do I find it interesting enough. There are much
more common and important cases where you can't use GLUT at the moment
and you have to resort to write your own GLX code than multithreaded
GLUT context support in my opinion.

I'm not trying to say that multithreaded GLUT is or should be the number one priority, but considering the multiple cores modern processors offer, I see it as the logical evolution of freeglut, whether it happens today, in the next release, or in a few releases.
For instance a long-standing grudge of mine is that I can't integrate
the glut main loop processing into my own select() loop as I can't get
the underlying X socket without resorting to terrible hacks.

One grudge I have is not being able to order a glut redisplay from a different thread without some sort of hack.
Here are a few other things I think could be improved:
How interesting or useful those features would be is not for me alone to judge, but I put them forth as proposals for freeglut 2.8.0.

Alex G.