You can have a reliable supervision tree even if s6-svscan is not your process 1. The supervision tree just has to be rooted in process 1: that means that your process 1 will have to supervise your s6-svscan process somehow. That way, if s6-svscan dies, it will be restarted, and your set of services will always be maintained.
Be aware, though, that pipes between services and loggers are maintained by the s6-svscan process; if this process dies, the pipes will be closed and some logs may be lost.
s6-svscan and the various s6-supervise processes might produce error or warning messages; those messages are written to s6-svscan's stderr (which is inherited by the s6-supervise processes). To log these messages:
In the following examples, we'll assume that /command/s6-svscanboot is the name of the script you are using to start s6-svscan. Adjust this accordingly.
Put an appropriate line in your /etc/inittab file, then reload this config file with telinit q.
Put an appropriate configuration file in the /etc/init folder, for instance /etc/init/s6-svscan.conf, then start the service with start s6-svscan.
# s6-svscan start on runlevel  stop on runlevel [!2345] oom never respawn exec /command/s6-svscanboot
systemd has its own way of supervising services. If you are a systemd user, chances are you do not need s6. If you are interested in using s6, I encourage you to also stop using systemd.
Put an appropriate line in your /etc/ttys file, then reload this file with kill -s HUP 1.
sv /command/s6-svscanboot "" on
Like systemd, launchd comes with its own way of supervising services; if you are a launchd user, you probably do not need s6.