By "officially supported" do you mean officially-supported by CM, or by device vendors?

From within Android, I see no such movement. In the short term security concerns have motivated the movement of more stuff into GMS, where it can be updated by Google. Eventually I think the larger update problem will be resolved and that movement will be reversed.

Actually, whenever they agree to not charge the customer, the bank charges it back. I know small merchants that have had it happen in spite of following all of the procedures as required.

Yeah. I think Kirt's ranting about the "tyranny of Google" is BS. Although I can sort of understand where they MIGHT be coming from after the Cornerstone mess - but that was probably a no-win situation for everyone involved.

That said, I fully agree with the people that are seeing a slow move towards AOSP becoming more and more closed source. One by one, the following happens:
Google wants to integrate GMS further with a given app (no problem here)
Google forks said app to add GMS integration (no problem here, although moving it to some sort of plugin-style approach might work better as it avoids what has proven to be the inevitable result)
Google stops development on the open-source component that the GMS-integrated component was forked from within AOSP, leaving it to rot. This annoys people and is where the perception that Google is slowly "closing down" AOSP comes from.

There's also the fact that AOSP's strict scope-limiting to Nexus devices only tends to cause people to not bother upstreaming to it - https://android-review.googles... for example

Also annoying is the fact that Google still builds AOSP using prebuilt kernel images, which often depend on toolchains deleted from AOSP. Also, AOSP uses kernel headers that just happen to match the actual kernel itself in structural organization but have different names, so Bad Things happen if you try to build AOSP against actual kernel headers now:
https://github.com/omnirom/and...
and
https://github.com/omnirom/and...

AOSP?
Omni? (I'm biased here - the history is that it was founded by a number of Cyanogenmod maintainers that left as a result of the Focal fiasco. However I'll be honest, a lot of the developers have burned out and as a result we're really behind on a lot of things...)
Some of the Omni guys along with people from EOS and Slim are talking about forming a project that is strictly limited in focus to hardware support. Some of the ex-Gummy guys already formed such a project (AOD) but a number of people (including myself) are holding back because they kind of rushed things - starting to code without planning the project, while the challenge of such a project is planning and organization/politics. Screw up the planning and organization/politics and best case is that you wind up "just another ROM".

AOKP is dead due to Cyngn hiring Roman
Same for ChameleonOS

As a former Cyanogenmod maintainer (I left the project as a result of the Focal fiasco), I'm 90% certain no officially supported device ever used flash memory for swap.

The closest I can think of was that some devices used zram (which Google added official support for in KitKat IIRC...) - zram was pseudo-swap where the system would swap into "compressed" RAM.

Yeah, that's the part that doesn't make sense to me. Why invest in Cyngn 6 months after you killed off every Android device in your portfolio?

The problem is that unlike on the desktop, the display subsystem on many devices is more than just the GPU. Also, the subcomponents of the display subsystem interact with other subcomponents in such a way that if an OEM makes changes, those changes ripple throughout the whole subsystem.

The end result is that if one component of the display subsystem (and this includes the camera, since it has hooks into the display subsystem to handle preview and such) is closed-source and deviates from the reference implementation for that platform, it's a nightmare of reverse engineering to get the other components open-sourced.

That's why, for example, most of the original CyanogenMod maintainers for Samsung Exynos4 devices ditched the platform. Samsung had reference source at Insignal, but it was vastly outdated (Their "ICS" source had significant architectural components that dated back to Gingerbread) and didn't even remotely match what ANY OEM used (Samsung's own handsets did NOT use the "gingerbready" components referenced previously). Getting that source usable with any real device was a nightmare. The kernel wasn't the issue, it was all of the HAL stuff - hwcomposer/gralloc/etc - especially hwcomposer.

Cyngn (the abbreviation I use to refer to Cyanogen Inc) does have access to all the proprietary goodies that should allow them to support a device very well, but so far, their track record has been to do no better than the OEMs they claim to be trying to provide an alternative.
Oppo N1 - didn't receive KitKat OTA until November 2014, 1 year after KK was released. Epic fail. Yeah, there were CM11 nightlies, but Cyngn staff will aggressively remind you that community builds (including CM nightlies) are NOT supported
OnePlus One - Their current state is "average" - many OEMs upated to Lollipop within a month of Google releasing it, Cyngn is at 3 months and counting.

Flourish.

Your example just demonstrates that Google really did allow Motorola to operate as a separate OEM, not directly influenced by the Android team. It's also possible that Motorola didn't have the option of releasing the specs because of agreements with the camera manufacturer. (Note that I don't know anything about that specific incident, and hadn't even heard of it until you mentioned it. I do know that Google would like its Nexus devices to be much more open than they are, but can't get there without becoming a hardware manufacturer.)

If that were an even remotely-likely outcome, it would have happened. Life is extraordinarily good at surviving and evolving new equilibria.

Meh, the history of life on this planet is one long series of massive, unexpected perturbations, ranging from ice ages so severe that the equatorial seas are covered with several meters of ice, to massive volcanic eruptions that block most global insolation for years, to massive meteor strikes. In addition, the ice core records show that the planet has undergone radical climate change (much faster and more extreme than what we're currently seeing) without any cause at all as far as we can detect, as recent as 60K years ago.

Certainly. Equally, we shouldn't ignore the fact that doing nothing at all (assuming we could) will also have disastrous consequences on our own habitat. Earth changes all the time, in all sorts of ways. If we want stability we need to learn to actively engineer the planet.

Okay, but the issue you're complaining about (pocket muting or hanging up) should be impossible on proper hardware regardless of the screen lock status. So with that out of the way, you just disagree with the screen lock behavior. That's your prerogative, but I don't think it's clearly wrong.

Ah, okay. Thanks for the clarification. Yes, there are good reasons that stock Android doesn't use swap, and I can see that people who change that could cause themselves lots of problems :-)

As I recall it was about not making it easy for users to download copies of videos. I could be wrong.

That's the economic system that was used in the USSR.

Then, one day you get distracted and don't see or hear the car backing out and CRUNCH! You become the one with the handicap.