First off, on WIndows, Streamlink Twitch GUI needs a helper utility called SnoreToast in order to display native notifications. Chromium still doesn't have support for native notifications, unlike on Linux (freedesktop notifications via DBUS) or macOS. This means that whenever a notification needs to be shown, snoretoast has to be executed and an action is performed according to its exit code. This isn't a perfect solution. There's also a named pipe which can be read from for other callbacks, but that's not being used or even relevant.

The last version that doesn't act this way for me is v1.11.0

The v1.12.0 release of Streamlink Twitch GUI bumped NW.js from 0.45.5 to 0.52.2. This included a bump of Chromium from 81.x to 89.x and NodeJS from v14.0.0 to v15.12.0. The change of the bundled snoretoast version in that release is irrelevant.

I don't use Windows, but the reason for the spinning/loading/hourglass cursor is how Windows handles process startups and GUI initializations. Windows basically waits until there is something for the user to see and it does that by showing a different cursor during that time.

The cursor replacement (called feedback mode) can be disabled via the low level Windows APIs (STARTUPINFO / STARTF_FORCEOFFFEEDBACK), but this stuff is managed by NW.js / NodeJS, and I don't have access to any of this from the application code and the public NodeJS JS APIs that are being used by the application code, namely child_process.spawn(cmd, args, options).

There was an issue in an old NW.js release in 2016 where the application itself was showing a spinning mouse cursor, but it's unrelated to this issue.

I don't know much about the NW.js and NodeJS internals, but something must've changed in regards to how child process spawning is implemented and how CreateProcess in the win32 API is called. The STARTF_FORCEOFFFEEDBACK bitmask needs to be applied to the dwFlags parameter value.

Spawning the child processes in detached mode unfortunately doesn't help, I just tested that in my Win10 VM.

This issue needs to be reported upstream on the NW.js issue tracker and an NW.js reproduction/demonstration app needs to be created.

As a small workaround, I could enable "Chromium Rich Notifications" on all versions of Windows, not just 7 (which btw will be dropped soon), which are notifications that are rendered by Chromium itself, so no helper process is needed. That wouldn't be ideal though, not just because those notifications don't follow the system theme, but also because of how the notification type selection and its order is implemented. If the order doesn't get changed, then rich notifications would need to be selected explitly, and if the order gets changed, then people who have chosen the automatic selection will use the non-native notifications by default.

Apparently, setting shell: true on the spawn options prevents the spinning cursor, and most likely any wrapper script would work as well, but both solutions are very problematic on Windows due to how shell tokenization works, which is insanely stupid. Since notifications contain user-generated content, I don't feel confident at all with this.

NodeJS's I/O is done via libuv, and here's the Windows implementation of the uv_spawn function and the git-blame of its dwFlags, which indicates no changes:
https://github.com/libuv/libuv/blame/v1.44.2/src/win/process.c#L1060
STARTF_FORCEOFFFEEDBACK was never set here, so I'm not sure what changed.

Here's some of the call stack:
https://github.com/nwjs/node/blob/nw71/lib/internal/child_process.js#L395
https://github.com/nwjs/node/blob/nw71/lib/internal/child_process.js#L266
https://github.com/nwjs/node/blob/nw71/lib/internal/child_process.js#L44
https://github.com/nwjs/node/blob/nw71/src/process_wrap.cc#L144
https://github.com/nwjs/node/blob/nw71/src/process_wrap.cc#L264

I'm currently having a look at refactoring the providers of the NotificationService. There's a solution for the mouse cursor problem by using Windows native notifications via the Chromium API directly, so that executing snoretoast is not necessary.

Chromium has added support for native "ActionCenter" notifications several years ago, but similar to notifications via snoretoast, only applications that have a shortcut installed in the system's start menu with an attached AppID are allowed to send ActionCenter notifications. If such a shortcut does not exist, then a "rich" notification gets shown by Chromium, which is rendered by the browser itself.

The snoretoast provider has a setup step implemented which installs the shortcut upon first execution via snoretoast.exe -install "name" "path-to-app.exe" "app-id". Another solution is creating the shortcut in the Twitch GUI's Windows installer, but that would only be a one-time action, and that could lead to the user not being able to see ActionCenter notifications once the shortcut got removed or replaced. And users which don't use the installer would also not be able to see ActionCenter notifications. Those shortcuts unfortunately can't be created via regular methods, as those don't support setting the AppID property. This is only possible by using certain Windows APIs.

Chrome on Windows faces same problem. Its own installer (and/or internal update mechanism - not sure) creates a shortcut at %ProgramData%\Microsoft\Windows\Start Menu\Programs\Google Chrome.lnk with its embedded AppID. Without this shortcut, ActionCenter notifications can't be sent. Quick DOM API example:

await window.Notification.requestPermission();
new window.Notification("title");

Streamlink Twitch GUI already implements notifications via the Chromium API, but this is only enabled for macOS and Linux as the native provider, and for Windows 7 as the rich provider.

If the shortcut could be created with the correct AppID, then the rich provider could be removed in favor of a single native provider (or something similar). Unfortunately, NW.js doesn't register the right AppID that is defined in the app's package.json manifest, which is streamlink-twitch-gui (or Streamlink Twitch GUI). The shortcut could still be created by running snoretoast.exe -install ... if the right AppID could be figured out. Then ActionCenter notifications can be shown via the Chromium or DOM APIs.