Just like "quiet", which is totally meant to affect userspace programs.
> It's a ridiculous clunky hack that stinks of large company coding practice: what they actually needed was a way to pass arguments to systemd itself.
Having a global "debug" knob would have been useful when one does not know if the problme lies in the ramdisk, plymouth, systemd, udev, lvm, whatever. Having a systemd-specific flag defeats that purpose.
> The logical way to do that in an OS that has to be portable and flexible is to implement a mechanism for the kernel to pass some of the arguments it receives to init. Because there's no reason to assume that init is going to be systemd, that there's going to be a procfs ready for it so as to be able to read the kernel's parameters, or that the init process can read it for that matter.
The kernel command line, readable from procfs, has been used for this purpose (see the "quiet" flag) for a very long time now.
> what do you mean "this can have unwanted side-effects", it works perfectly fine on my system.
It worked perfectly on every system until the kernel bug triggered the feedback loop.
> The fact that the developers (again, it's a known pattern) decided to play the PR game and call it "expected behaviour" doesn't make it less of a bug.
It was "expected behaviour" in the presence of a kernel bug, which is why it was obviously not generally "expected behaviour" as you seem to imply.