> ..the systemd approach was (and still is?) convert (or "generate")
> sysvinit scripts into systemd unit files.
Still is. But that is only half the issue. As mentioned already, any
attempt to run a sysv script is intercepted by SystemD. The
corresponding unit file ('generated' or 'packaged') is executed
*instead*. This is seriously flawed (take the simple case where the
sysvinit script fixes up the ENV for a daemon service in some custom
way, SystemD fails to pass that on in it's 'generated' unit file).

I recently had an issue where SystemD failed to stop a service (to
reload the configuration on restart) after an upgrade. Investigation
revealed that SystemD could no longer identify the running daemon, and
as it could not find it, claimed it was already stopped.
'killall -TERM' found it fine.

> "All" we need to do, is reverse this approach to support or convert
> "native systemd" software with "no non-systemd support" into something
> we _can_ use.
Reversing \ converting the unit scripts is not enough, Time services
have been hooked by SystemD, Networking has been hooked by SystemD,
Logging is hooked by SystemD, UDEV os hooked by SystemD, etc, etc, all
that needs to be undone too.