So we see again that you don't really know what Linux is.

You go the newspaper road, defining Linux as the union of everything that in some way is run on a machine that happens to have a Linux kernel.
But that same lousy getty you found could just as well be called BSD or something else. Linux is just one specific kernel that implements parts of the platform for a Unix clone.

Linux doesn't have any runtime library. It's often GNU code that is used. But then GNU have their own kernel too.
Would you call a machine running FreeBSD, NetBSD, Hurd/Mach, ... for Linux just because it's a Unix clone?

What I did post about really was Linux. Because the Linux kernel is what Linux is. Then Debian, Ubuntu, Red Hat, ... are packaging of a Linux kernel with GNU, BSD or other applications to form a complete OS. Maybe you could tell us how many years you have activelly worked with Linux development before you start using the expression "gone off-the-rails"? The biggest issues with Linux and embedded really is to select a processor where the architecture part of Linux is badly designed. No developer with more than basic unix development skills should have any issues with any getty.

Yes - I would be extremely surprised if you can't find a getty (there really are many of them out there) that has bad documentation. But what is the relevance to Linux?
And as I noted, the most common thing for people who use Linux in embedded environments is to use Busy-Box (http://busybox.net/) to simplify the life and not have to figure out which of ten getty, which of ten shells, which of ten init, ... to use.

I can find lots of terminals for Windows - does that have any relevance to Windows itself or to the Windows Hyperterminal? Does a badly documented terminal software for Windows mean that Windows is badly documented?

But no one is debating the need to have a view about "what's required".
But your claims are a million times stronger, when you claim that no single code line may be written until there are enough documentation that no single reenginneering may ever be needed. It is very often the case, that coding is the only practical route to decide which design to use to fulfill the requirements.