15s is too aggressive IMHO. Fedora have amended their proposal to be 45s [1] which is probably more reasonable. Similar to Fedora, Arch should probably consider this at the distro level (RFC anyone?) instead of at the pkg level.

[1] https://meetbot.fedoraproject.org/fedora-meeting/2023-01-17/fesco.2023-01-17-17.01.html

I agree with Toolybird... This is a change we should not include on our own, but propose it upstream.

Fedora does this because upstream got stalled.
Read https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer

Specifically this part:
An attempt has also been made to have the unit timeout changed in upstream systemd. That attempt did not go anywhere, despite various efforts to move it along. We are no longer comfortable waiting for upstream changes to land.
And this PR as reference in upstream: https://github.com/systemd/systemd/pull/18386

Does upstream's proposed change address the issue for you? This passes all tests for me on stable-252 and main. If it works for you then you could ask upstream to rebase the change and run the tests again.
If upstream's fix does not address the issue for you, then please provide them with additional feedback on what other changes are required.

?

I don't have a specific testcase where this timeout is annoying. Sometimes a service just doesn't want to shutdown. I've seen the login manager (sddm), networkmanager and a couple others i don't remember by name.
It makes sense in a general approach - preferably on systemd upstream level, but if they are stalled in discussions then on a distribution level - to force kill applications after X seconds.
A patch should most certainly not be done on a user-level, as you seem to suggest now. That patch, if not careful with updates, will be gone without noticing it once there is a systemd update.

I don't care if X is defined as 5 seconds or 90 seconds or anything in between. But I do care if there is no X and a shutdown can take indefinitely because of an applications not shutting down properly. This, although rarely, does happen.

The upstream change would not help for sddm or NetworkManager as it only changes the timeout for user services not system services.
I was assuming you had a reproducible issue this addresses that you could test the patch against.
Upstream stalled as the PR introduced test failures. If a rebased version of the commit no longer does I expect it would be accepted.
Edit:
You are aware you can locally set in /etc/systemd/system.conf for system services DefaultTimeoutStartSec DefaultTimeoutStopSec DefaultTimeoutAbortSec DefaultDeviceTimeoutSec
and in /etc/systemd/user.conf for user services DefaultTimeoutStartSec DefaultTimeoutStopSec DefaultTimeoutAbortSec
which will be preserved through package updates subject to normal config merging.

Ohh awesome! I wasn't aware of that, thanx for letting me know!

Now this makes more sense. In that file i see defaults of 90 seconds but commented out.
I think want i actually want to suggest is to have this enabled by default!

Just got a mail about an update in this issue (title change) :)
It does remind me of this one though.

I - at least once - had the super annoying situation where i remotely ssd'ed into my machine and had to reboot it for something (i think it was a kernel update).
It never came back.
Just when i got home a couple days later to check what the hell was wrong i noticed it was waiting for a process to exit (no clue which one it was, too long ago).
While that was a weird once in a whatever big number event, i did many more times have the same situation where it took minutes up till hours. Nearly always it eventually works...

Having the default enabled (be it 15 or 45 seconds or even 5 minutes) would be much appreciated.

I strongly disagree that arch should not do this in hopes to wait for upstreeam to get their act together. No clue what kind of political games they play, but this is imho an essential feature of a stable system that needs to be enabled to safeguard against crap applications not wanting to quit.