[Android Software Development] guitardedhero:
Man, this is embarrassing...

In Opus, a setprop script outside of the execution directory for one of two root management solutions - Magisk (/magisk/.core/*.d and /magisk/.core/<module>/) & SuperSU (/su/su.d (though, never wise IMHO. The only content ever present must be only from Chainfire) and /system/su.d/ (the responsible location for any SuperSU installation) - will only execute automatically if existing as /system/etc/init.d/arisesound_setprop, when installed.

The name change adding disabled to the name of the script was a way to disable the script's automatic execution as well as "announcing" (visually, of course) the effect of the name change, was intended to only be a one time test build change.

At the time, a percentage of the properties and values set were suspected of causing multiple and repeated issues/bugs.

This obviously is quite a severe oversight on my part as the majority of users benefit greatly from many of those property values, and the unaware (you can never expect a user to conclude an "advertised" component as being intentionally "broken") have, in the least, been spending measurable time auditing the getprop output with the sound system installation.

Finally, yes, you are absolutely correct. The best way to remember is to understand its lone possibility of executing:

/system/etc/init.d/arisesound_setprop

In order to avoid creating more confusion and head-scratching, I'll explain why a particular directory, widely known for quite some time to no longer behave as designed through recent Android OS iterations, is used for all scripts except for one script in /system/su.d (Magisk module accomodates this as well).

I've addressed this before, but good luck finding it and/or kudos for convenient timing.

Not so much with Magisk 13.3, SuperSU is not very flexible with regards to the timing and order of the different boot stages from beginning to end.

When harnessing as much control and operations as you can with multiple scripts, timing and order is often critical.

The default assumption with Opus is that no init.d support is available. The single script in /system/su.d will initiate the entire execution process, consecutive scripts instructed to run via previously executed scripts.

Init.d support would, in fact, make the identical "start-to-finish" a much more challenging task.

However, init.d support would compensate this loss of (my, in this case) control by removing any requirement for rooting a device (for numerous scenarios), as root is only necessary for these scripts, much of which is responsible for various functionality in current/bleeding-edge Android firmware.

It's all about starting just one script. If you have the ability to automate the execution of a single script, infinite script executions are possible (facts, not real-world events), unfortunately, genuine init.d support has never resurfaced when crippled several Android OS versions ago. Any excitement for potential init.d solutions quickly end with disappointment when found to merely be a SuperSU script to execute the contents of /system/etc/init.d, precisely what I do in Opus and before, except the fact that init.d support is not an "advertised" feature, of course. I use it for potential control, but it could be a directory of any name. But, if one day... init.d support is achieved, I will get to relive those days when I provided the first ever ViPER4Android installation without a trace of root or BusyBox. (I even had an unrooted Nexus 6 rom series, named ViPER|Atmos of course, lol).:good: