while sxmo did eventually switch to upower, it is important to note that upower does not actually handle the shutdown on low power itself, but simply places a shutdown request to logind [1]

This means automatic shutdown on low power is not working under sxmo since it is not logind compliant. Assuming this is not planned to be changed in the foreseeable future, maybe sxmo should at least be on the lookout for upower's action state/signal, then initiate the shutdown action manually

[1] https://gitlab.freedesktop.org/upower/upower/-/blob/1146047df93c0da14bdd3e5a31b691289e96a84c/src/linux/up-backend.c#L615-623

Update: autorotation did not work on the N900 out of the box, even though the accelerometer is exposed on kernel's iio subsystem, and has all the paths required in the autorotation script. The issue was most likely due to the 'gravity' setting, and I do not know where that can be found. With iio-sensor-proxy, it works at first go.

Patch submitted: https://lists.sr.ht/~mil/sxmo-devel/patches/51350

NB:

1. iio-sensor-proxy needs to be manually added to autostart services (rc-update add iio-sensor-proxy default)

2. out of the box, iio-sensor-proxy does not allow the regular user to 'claim' sensors, which is needed in order to monitor them. The following PolicyKit rule is needed:

        polkit.addRule(function(action, subject) {
          if (action.id == "net.hadess.SensorProxy.claim-sensor" &&
            subject.isInGroup("plugdev")) {
              return polkit.Result.YES;
            }
        });

It should be saved as /etc/polkit-1/rules.d/01-sensorproxy.rules. I am not sure what group is better recommended instead of plugdev

it tells you right there:

[ERROR] Could not change MAC: interface up or insufficient permissions: Operation not permitted

try to reboot, so this applies from boot.

Also, do not use macchanger. As you pointed out, NetworkManager can do the MAC changing itself. I thought you would actually remove the /etc/NetworkManager/conf.d/00-sxmo.conf...

while that's true, it means, for example, that if Nokia N900 support is added, sxmo would needs to know about 3 different ways to talk to proximity sensor, for example:

1. the 'normal' iio subsystem way
2. the ssccli way, specific to SDM845
3. the evdev way, specific to devices such as N900 (and Google/Asus Nexus 7)

Now wait until another device shows up, needing a 4th way!

iio-sensor-proxy already abstracts these sensors. There's a client, which I think an sxmo implementation would need to use since direct dbus calls cannot work (sensors need to be claimed before being accessed, and shell scripts cannot hold such claim because they're short-lived).

I'll write a proof-of-concept patch and will see if I can get it working

PS: the merge request https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/375 did get merged :-)