It shows that the kids running systemd don't get the concepts of stderr or exit statuses.
No, this example shows that in previous 'init systems', the init system was adding no value after the default runlevel was reached. You were basically just running a script, and you had the option to check its return value. It just so happens that the init system would also run this script when changing to the relevant run level (but not in exactly the same way).
In systemd, systemctl tells systemd to start the service. systemctl doesn't exec the script in question itself.
The difference is that, under e.g. sysvinit, while a server remains at a specific runlevel, init scripts are no different than any other scripts. This also means that there are potential problems, where the last person to have started the service may have had different environment variables which made the service work (PATH, LANG, LC_ALL, JAVA_HOME etc. etc.), now when it fails (or the machine is rebooted), you (or init, in the one case it actually does something) try and start it, and it doesn't behave the same way. Go compare the /proc/$pid/environ for a service on a sysvinit box that was started at boot to the environ if you restart it later. In systemd, since systemctl isn't forking the init script (or similar), a clean environment can be gauranteed.
So, since systemctl isn't exec()ing the script, systemctl doesn't have to wait for the execution to finish before it returns.
Setting Type=forking will change the behaviour to what you expect. Why? In the case of a forking daemon, the init system *should* wait for the process to fork before it returns. Maybe there should be another option for Type that doesn't require a PID file but does return the exit status.
However, instead you can always call sytemctl is-active broken_systemd after-the-fact. But, if your 'service' may take some time to get through it's initial checking, maybe you are better off using Type=forking.
