Playing around with disable/enable and the exploit: Root always has a /bin/sh shell "Disable root user" removes the ShadowHashData from the directory services entry for root The bug sets ShadowHashData to the hash of an empty string.
Now, ShadowHashData is a complex DS entry. I've never seen passwords represented this way in other OSX versions. I think this password storage format is new.
I strongly suspect the bug here is one related to OSX attempting to upgrade the password to the new storage format and when it does that, it inadvertently stores the password with a hash of null.
This should be very trivial for Apple to fix that (and thus "disable" the root user) by just removing any ShadowHashData that is solvable by an empty string.
The factors that differed from my laptop, where it worked until I set a root password, as that her machine was a fresh install, and she is not admin (a managed machine).
I think the feature that caused this is related to upgrading pre-high-sierra user password hashes to high-sierra-style hashes.
The fact that it works for situations where the password is null is a/the bug.
If we assume that ShadowHashData hash was introduced in High Sierra, I thought it was safe to assume that a crypt hash would only origin from a pre-High Sierra install. Unless, of course, they are used as some form of default value (such as when disabling the user)...