Is there a reason lockFor(nodeId) returns false when nodeId has the lock? Note that allowing mutex-gate-ACQ to be pulsed multiple times might create an issue if you are using mutex-break to force all other parts of the program to end so you can take execution in a new direction (the loop pulsing ACQ multiple times is likely to fire again and re-acquire the lock).
It seems Mutex will often be used with a device (but not always). Would it make sense (or even be possible) to have a mutex-dev node that takes in a DEV (generic type?) and outputs a single pin with both Mutex & device (MUXD)? There would need to be a 2nd node to split MUXD into DEV & MUX so existing nodes do not need re-written. This would not improve functionality, but would reduce pin-count on nodes needing to pass both (which would be all nodes using a device we are managing with mutex).
I just realized, rotate-slow functionality changes slightly if lockFor(nodeId) returns true if there is a lock for that nodeId. Currently button press is ignored if servo is in motion; if lockFor(nodeId) returned true when current node has the lock, the button would restart the 1st rotate-slow if it was active (it would still ignore button press if 2nd rotate-slow was active) – not that it would make a difference in this case since it would update current position and continue to same destination, but in some cases the difference might be dramatic (like if rotate-slow assumed start position instead of using current position).
Whether a mutex should lock successfully if already locked by a particular node or not depends on what a xoder trying to express. It might happen that re-entrant mutex is required and exactly the opposite is possible. Maybe, there should be more variations of the lock nodes
A topic for an experiment. This involves taking generic as an input and outputting a new custom type that is generic too. I don’t see a straightforward way to achieve this, but I’ll think about some tricks.