Those are protective gear for hypergolic propellants. Wikipedia says the X-37 engine was changed to use nitrogen-tetroxide/hydrazine. Those are both toxic, but deliver much more reliable engine restarts, hence consistent with the X-37's long-duration mission objectives.

"shrinking gap" is definitely the right way to think of this.

Automatic emergency braking, adaptive cruise control, "lane-keep assist", are already available in selected car models from most major manufacturers today. Tesla's autopilot is just these technologies on steroids. If Subaru or Volvo were less cautious, they could be shipping a highway autopilot today too, at least based on what their production cars already can do in an advisory/emergency role.

Meanwhile, for manual driving I will be very surprised if some form of automatic emergency braking isn't mandated within 5 years on new cars.

This has to depend a lot upon the kid. My 6 yo really wanted to learn to program, so we did it over spring break one year.

I sat with her for a 1-3 hours a day for a couple of days, individually teaching core concepts. During this time I let her operate the computer exclusively. I watched, gave advice, drew pictures on paper, and didn't use my phone. I think being hands-off but present and engaged is critical. When I was a teenager I used to tutor grownups on PCs and found that having them drive the computer was the most effective way to ensure I wasn't losing them. After the first few days I found I could teach her something, make sure she was doing OK with it, and then go away for a few minutes to do something else and return to answer questions.

I had drawn up a list of concepts I hoped to teach, and shared that plan with her and used that as a general direction. Nonetheless, what we actually did was directly guided by her interest level and enthusiasm each day. I aimed to keep her engaged and focussed and adjusted speed and content to do so.

I opted to use a fairly old language environment, Logo. Drawing pictures is directly appealing to kids, and using a text-based programming environment exposed her to syntax and learning to edit actual code right from the get-go. I don't think drag-and-drop learning such as one gets with Scratch or Blockly translates very cleanly to other programming environments because you're only learning procedural concepts, not that commas and quotes and other kids of precision matter. For instance, because she needed to know syntax I showed her how to access and read the docs. That led her to discover that the specific Logo we used, ACS Logo (Mac), has speech synth support. Then she started using the speech synth to narrate her drawings. That was pretty cool and a big success she could claim for herself.

We did not make it through my whole list of concepts, but she did attain independent fluency with a subset of Logo and programming in general. A bit over a year later she periodically updates/extends her programs. And I recently watched her independently learn 2 other programming languages, one via watching videos, and another via an online course. So it's clear she is able to apply what she learned to new contexts.

In a telling comment that seemed to me to confirm my choice of Logo, she learned quite a bit of Python and then complained the language couldn't do anything she cared about. Of course that's naive, but it illustrates that you need to pick an environment with features that will appeal to your child early on, not in some far-off land after one has learned the basics. In this vein, you might also consider introducing a kid-oriented robotics microcontroller like the Hummingbird Duo. These have the appeal of making physical things light up, move, and sense. This will likely rate much higher on a kid's priority scale than building a website or crunching numbers. My daughter is now learning to build simple robots with a Hummingbird Duo and a bunch of sensors and servos and likes it. And even though this too is programming, it's a very different set of complexities than what she did before.

Good luck!

Topic-Creep Warning: The following is more about GUIs in general, and the "comparative-theology" points raised in this thread than about GUIs just for installation.

what were the differences again?

I was a Windows advocate in a Mac world (just to be contrarian) for many years, so I could argue both ways on this, but you're missing the point by looking at resizeable windows, buttons, icons, etc., as those are pretty basic parts of a GUI. What's far more important are the interpretations of these graphics, as well as what the user does with them in terms of direct manipulation.

The Mac and OS/2 have both been significantly ahead of Windows in certain UI areas, but MS has persistently incorporated features of its competitors in the Windows GUI. Unfortunately, these implementations are typically more flash than substance, but at least Windows users get some of the innovations, as well as some uniquely MS innovations. (e.g., the "Start" button and task bar)

Consider that direct manipulation of the directory/file structure will always be easier for casual users on a Mac. It's not that you can't drag and drop icons on Windows, but that the underlying Windows/DOS directory heirarchy are just too complicated. Applications consist of tens or hundreds of files that have to be moved together, for instance, rather than a single icon. Unix will face the same stumbling block. Once again, I'm talking about casual users, not sysadmins.

OS/2 is a weird case. I was an advocate in the OS wars on the OS/2 side, but my ardor has long since cooled and I'll just cite the facts as I recall them. Versions 2.0 (circa 1992) and later attempted to implement a GUI known as CUA '91 (aka, "The Workplace Shell"), which was developed in IBM's Cary, NC human factors lab. Among other innovations, CUA '91 was very visually "object oriented", and pushed the use of right-mouse-click "context" menus, "container controls", and the notion that any given object may have multiple possible "views". It encouraged widespread use of direct-manipulation, not only of files and directories, but also of all sorts of "objects" within applications. And it pioneered (as far as I'm aware) the use of "Notebook" controls for application and OS settings.

CUA '91 was really cool. The implemented WPS was close, and I still prefer it over Windows, but to really shine it needed applications which conceptually share the same interface. Those never got developed.

Windows 95 incorporated the notebook controls and right-mouse-click menus, and copied the look and feel of the container controls (though I don't think the functionality was exposed to applications developers). There are also some interfaces that one could argue would permit applications developers to implement the same sorts of direct manipulation. Could implement that is, if those application developers already knew what they were doing and could agree on the protocols for using the messages in question.

Oh well. Nobody seems to be flogging the direct manipulation horse now anyway. The Internet and an obsession with browser-interface and functionality have eclipsed everything else.