Unless someone has an objection, we will drop all the specifities but one  that openSUSE introduced during the integration of systemd in the SUSE distros and that shouldn't be necessary anymore.
As you might know, several months ago we got rid of all remaining SysV init scripts shipped by openSUSE by converting them into (very basic) systemd unit files. Additionally, OBS should refuse to build a package that would introduce new scripts.
At this point, one temptation would be to entirely drop the whole support of the SysV init scripts but I think it doesn't really makes sense at this point because:
- some of you might use 3rd party packages that still ship SysV init scripts;
- systemd upstream still supports them anyway
Here should be an exhaustive list of the differences that are going to be wiped off:
- support for early boot scripts is removed. Basically such scripts were used to start generated services with "DefaultDependencies=no". Those scripts had usually a filename starting with "boot." and theirs enablement symlinks were located in /etc/init.d/boot.d/;
If you have any scripts of this type, please convert them into a proper systemd unit file. This task could be as simple as copying the generated unit file by systemd from /run/systemd/generator/ to /etc/systemd/system/.
Please note that you'll likely need to add append an appropriate [Install] section in your service unit file, which will allow you to enable the systemd unit file afterward.
- the virtual facility named "$all" is no more translated into the default.target target and will be considered as a regular service name;
- the '+' marker in the front of the name of a dependency losts its special meaning and is considered part of the name of the dependency itself;
- the systemd rpm macros will be updated to get rid of the automatic conversion of SysV init enablement symlinks into systemd enablement symlinks that used to happen when a package converted its scripts into unit file and after it was updated
It's very unlikely that any 3rd party packages rely on these SUSE specificites as they should ship SysV init scripts that should be made portable across the different type of distros. But please let me know in case your 3rd party package ships a SysV init script relying on any of these listed features.
Amongst all of these changes, I think only the latest one is the most impacting. In case a 3rd party package converts its scripts into unit files, you'll have to make sure to either preserve the enablement symlinks in /etc/init.d or explicitely enable the newly introduced unit files.
 Unfortunately, we will still have to keep the SUSE specific patch that handles the dependency "Required-Start:" specifically otherwise dependencies listed here might not be started.