I guess there are more dimension to this problem:

• At first it isn't ensured that SBD_WATCHDOG_TIMEOUT is the same value on all nodes - hence pcmk__valid_stonith_watchdog_timeout() to check if stonith-watchdog-timeout works for an explicit node that otherwise has to immediately shut down resources or better never has started any.
• And the cluster has to agree in some way to a common real timeout value in numbers. It is crucial that the node that actually observes watchdog-fencing has a number at least as high as the number derived from SBD_WATCHDOG_TIMEOUT on the target node.
• For some time we now support nodes in the cluster that do support watchdog-fencing and others that don't. Otherwise you could have watchdog-fencing just enabled if all nodes do have a proper hardware-watchdog that is usable for SBD. Of course it enables the freedom to decide where you want watchdog-fencing and where not - for whatever reason. So it isn't even possible to do the automated calculation on all nodes.

Thus the concept currently implemented is dangerous/screwed anyway. So we should either drop the feature or go for something more complex.
Only real thing coming to my mind is that each node when it joins the cluster somehow communicates the value it would derive locally and some internal representation of stonith-watchdog-timeout is increased cluster-wide. But can we be sure that we've already seen a node before we are fencing it? Probably not.

Could we pass the feature to highlevel tooling somehow? When SBD is enabled pcs anyway does some sanity checking (e.g. existence of watchdog-devices on the nodes). It as well creates a quite minimalistic version of sbd-configuration /etc/sysconfig/sbd with SBD_WATCHDOG_TIMEOUT (noway around it being set to the same value on all nodes ) so we might as well have it set stonith-watchdog-timeout to a reasonable value if requested (or even per default).
If configuration is changed afterwards on a per-node basis validation would be done on each node as of now. (I mean per the definition of validate as of pcmk__valid_stonith_watchdog_timeout.

Revisiting this, we should check whether negative stonith-watchdog-timeout is either used by pcs or documented anywhere downstream. If not, just drop the auto-calculation feature and require nonnegative values.

If we do want to keep auto-calculation, this task can just be about using 0 for invalid values (for 3.0.0), and we can separate a new task for improving the auto-calculation (possibly using a new special node attribute set when the controller joins the cluster).

Another possible improvement is that instead of a bad value causing the node to immediately shut down, it could set a new special node attribute that would cause the scheduler to treat it as being in standby.

In T749#13824, @kgaillot wrote:

Revisiting this, we should check whether negative stonith-watchdog-timeout is either used by pcs or documented anywhere downstream. If not, just drop the auto-calculation feature and require nonnegative values.

It doesn't look like pcs specifically uses a negative SWT... at a glance it might not even accept it (haven't tested). The validator function requires the property to be greater than _get_local_sbd_watchdog_timeout().

return validate.ValidatorAll(
    [
        _StonithWatchdogTimeoutValidator(
            "stonith-watchdog-timeout",
            _get_local_sbd_watchdog_timeout(),
            severity=severity,
        )
    ]

Negative values don't seem to be documented in the RHEL HA Add-on product docs. I can't speak for SLES or elsewhere right now.

Bah. It's not in the product docs but it is in the design guidance article.

Since Pacemaker 2.0.0, setting this value to -1 means derive stonith-watchdog-timeout from SBD_WATCHDOG_TIMEOUT automatically. Red Hat does not recommend using this feature as there is a danger of split-brain when SBD_WATCHDOG_TIMEOUT is set inconsistently with different nodes.

https://access.redhat.com/articles/2941601

Let's just drop auto-calculation and use 0 for negative or invalid values.