It is currently implemented in OpenGLUT with a GLUT_BORDERLESS display mode flag. (See glutInitDisplaymode().)
Menus use such windows. (See OpenGLUT Menu Window Proposal.) However, there are some problems to date with using menu windows for general windows, and vice versa. On the one hand, the windows presently used for menus have peculiar behavior for keyboard input (on X, some window managers will not give keyboard input to menu windows unless OpenGLUT forces the issue---which can violate the user's focus policy). Another problem is that menu windows do not respond well to virtual desktop paging. There is some hope that both can be addressed by using a parent window, which can act as a proxy for these events. This is outlined under the menu window proposal.
The contrary problem is that there is as yet no known universal way to acehive a borderless window without, at least on some window managers, doing what the menu windows do. It may be practical to identify the current window manager at run-time and choose an appropriate method. One OpenGLUT developer has described this as ``hacky'', and it is not clear that such a method would be acceptable, if it were the only method available. The menu window concept appears to be good enough to handle menus, and menus are highly desirable. Borderless windows are also highly desirable, but if they cannot be achieved in a uniform manner, it would neither be acceptable to remove the concept of menu windows nor to cause menu windows to become normal windows on some displays. (So, at least, is held by the author of this proposal.)
In particular, it is proposed that a new symbol be defined: GLUT_BORDERLESS. This symbol will be a bit flag to pass to glutInitDisplayMode(). When a borderless window is requested, OpenGLUT will provide a window that is as much like a standard, top-level window as possible, and will also try to remove the borders and decorations, so that the only graphics created for the window will be a drawing space for the OpenGLUT application to draw on, using OpenGL.
This feature is currently implmented in an experimental form. In order to get reasonable behavior of keyboard input on some systems, it is necessary to redirect the input focus. The manner in which this is done may undermine input-focus policy on some systems. We are considering other mechanisms to support borderless windows.
This list may seem familiar, and that is hardly a coincidence. The potential uses are the same as for menu windows, if we can unify them.
Additionally, menu windows ideally should be more or less immune to being resized, moved, or pushed behind normal windows. Borderless windows, on the other hand, are not so privileged, and should be subject to normal window operations.
In response to the original version of this proposal, the following changes are tentatively made to OpenGLUT:
The biggest semantic problem that this proposal has is that an unmanaged window is borderless. A better name may be needed than ``borderless'' (though ``undecorated'' has the same problems).
On the other hand, reversing the implication of the two types seems at first blush to make the support more complicated.
The intent was that the original experimental implementation of GLUT_UNMANAGED should be split in two. This will allow both features to be explored more comfortably.