This is the default (and the only) behavior. It is not explicitly documented, but is implied by systemd's operation logic.
systemd.timer(5) reads:
For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses.
systemd(1), in turn, describes the concept of unit states and transitions between them:
Units may be "active" (meaning started, bound, plugged in, ..., depending on the unit type, see below), or "inactive" (meaning stopped, unbound, unplugged, ...), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called "activating", "deactivating").
This means that the triggering of a timer leads to "activation" of the matching unit, i. e. its transition to the "active" state.
If the matching unit is already "active" at the time of "activation" (for a service unit, this means "the main process is still running", unless the service unit has Type=oneshot and RemainAfterExit=true), it should be obvious that no action will be taken.
In fact, the script is running. As pointed out by Bigon and in the bug report the touch just cannot take effect because the file system is already mounted read-only when the scripts in /lib/systemd/system-shutdown/ are executed.
One can prove this by mounting and fs read-write before the touch:
#!/bin/sh
mount -oremount,rw /
touch /test
mount -oremount,ro /
Now the /test really appears after a reboot.
However, this also means that running my script through this folder will not be useful since it will happen too late.
In order to write to log files etc. one needs to run the script earlier through a service as suggested by Bigon. I explain this at How to run a script at shutdown on Debian 9 or Raspbian 8 (Jessie).
Best Answer
Are you thinking in terms of running as root? This is essentially for non-root users.
The concept "seat" is for situations where you want to service a maximum number of local users with a minimum amount of hardware (e.g. for schools or similar).
Computers can have multiple displays, keyboards and mice connected to a single desktop box, so with systemd, one desktop with two displays, keyboards and mice can provide two separate GUI sessions simultaneously if desired.
In a normal single-seat configuration, any hotpluggable USB devices normally have their device node permissions set so that a locally-logged-in user can automatically use them, but users logging in remotely (e.g. with SSH) cannot use them unless they are root or members of special user groups like
plugdev.With a multi-seat configuration, any such devices will by default belong to the default seat
seat0: the administrator can configure specific devices to other seats instead.