> I think his point was that window frames should be like dynamically typed polymorphic collections possibly containing multiple differently typed components that can change over time (like JavaScript arrays), not statically typed single-element containers that are permanently bound to the same component type which can't ever change (like C variables).

Well, dynamically typed, yes, and changing over time, but I don't think he was talking about sticking your editor and your command line in the same window at the same time. Rather, you could run a program in an mpx window on the Blit, and it would draw in that window until it was done, and then you would get your shell prompt back in that window.

I know this isn't really related to the overall question of end-user customizability and composability that you're focusing on here, but I dig the olwm-style pinned dropdown menus in your last screenshot there. It's a shame neither Open Look nor olwm nor olvwm ever did antialiased text — I know it was important for the window manager not to eat the entire palette of your cgfour or NCD, but when all your chrome text is black on slate grey, a couple of greyscale levels would have gone a long way.

Your other links are timely, since I'm trying to figure out how to do the BubbleOS windowing system Wercam this week, maybe using Unix-domain sockets and shared-memory bitmaps, or rather pixmaps; the thing that sounds most inspiring to me is Genode's nitpicker, but supporting the interposition-based design of the nitpicker window manager would require either an extra copy of all the pixels (to put them in the right place in the framed window) or a draw command that involves a whole sequence of rectangles instead of just one. I'm kind of thinking that by default windows will be embedded in my shell, like graphics in Jupyter, and then I'll see how things go from there. https://gitlab.com/kragen/bubbleos/tree/master/wercam