Ian Jackson's general resolution to prevent init system coupling has failed to pass, the majority vote deciding that the resolution is unnecessary. This means that not only will Debian's default init be systemd, but packages will not be required to support other init systems. Presumably, this means that using other init systems on Debian (without using systemd as a base) will not be possible without major workarounds, or possibly at all. It also leaves the future of Debian projects such as kFreeBSD unclear, as systemd is linux specific.
The vote results can be found here
The winners are:
Option 4 "General Resolution is not required"
Option 1 "Packages may not (in general) require a specific init system"
Can someone explain, in a technical manner, why this was not desired?
It was and is desired. Systemd, however, is not an init system. It is a cancer.
Proponents cannot point out the former without revealing the truth of the latter.
A daemon/service should not require init source code in order to build itself. Init should not require the daemon source in order to build. They should both be capable of building without knowing about each other. An optional intermediary that understands the daemon and the init can be used by the init system to start the daemon. That intermediary is usually a configuration file and/or script that the init understands. It depends on both the init system and the daemon. This allows you to use the same service with various init systems. The only thing required to make the service function with a new init is a new intermediary. The developers of the daemon/service don't even have to know about the new init system. They don't care about init systems, they care about their service. Usually a distro package manager would care about such things.
An alternative is the service developer using defines that can be toggled on and off at build time. So it becomes possible for a service to optionally depend on a specific init/library. This allows for the developer to directly support functioning with a foreign project but still allow the service to function if that foreign project dies, is forked, or becomes deprecated.
If you tie yourself to a foreign project then you tie yourself to its fate. If you want your software to continue functioning no mater what happens with the rapidly fluctuating open source ecology then you need to minimize hard dependencies.