The s6 ecosystem is made of several parts, which are mainly the following:
As explained in this presentation, an init system is made of four parts:
The s6 package obviously provides part 3. It also provides part 2, because s6-svscan is suitable as being pid 1 after some small setup is performed.
Part 4, service management, can be provided in a variety of ways. The s6-rc service manager is the natural complement to the s6 process supervisor, but it is not the only possibility. The anopa package also provides a service manager designed to work with s6. And, at the expense of tight integration with the supervisor, it is possible to run a "traditional" service manager, such as sysv-rc or OpenRC, with an s6-based init system. This flexibility is possible because service management is one layer above the mechanisms of init and process supervision.
Remains part 1. And that's where s6-linux-init enters the picture.
Part 1 of an init system, the /sbin/init program, has been purposefully omitted from the main s6 package, for a simple reason: s6 aims to be portable to any flavor of Unix, and it is impossible to implement /sbin/init in a portable way.
For instance, to do its job, s6-svscan needs a writable directory. Such a directory may not be available at boot time, before mounting filesystems, because the root filesystem may be read-only. So, at least one writable filesystem (typically a RAM-backed one) must be mounted before s6-svscan can be executed and be pid 1. And mounting a filesystem is a non-portable operation.
Moreover, the sequence of operations that a /sbin/init program needs to perform before executing into s6-svscan is a bit tricky. It can be scripted, but it's not easy, and since it's so early in the lifetime of the machine, there's no safety net at all (the supervision tree itself, and the early getty, are supposed to be the safety net, and they're not there yet). So it's better to automate these operations.
s6-linux-init aims to provide a fully functional /sbin/init program that executes into an s6 supervision tree with all the necessary support services already in place, as well as the corresponding shutdown commands. It also aims to be flexible enough to accommodate various needs and be compatible with any user-chosen service manager.
As usual, it is about mechanism, not policy.