• Appreciate the extremely thorough bug report and try to get a reproduction case on a WB dev's machine, perhaps on a fresh Windows 11 VM using the unattended deployment XML I've been provided.
• Take a look at whatever interaction is “cutting off early” as mentioned here by bdsams. Luckily computers don't run on “looks like”, so it will be possible to introduce some debug logging where something is invoking something else and is known to be the failure point.
• If a reproduction case can be found and it isn't due to something WB can directly accommodate, introduce an error message telling the user what is wrong instead of failing silently. There is already precedent for WB detecting and alerting for unsuitable conditions as shown by the “not installed correctly” message.

As a developer I also understand that these things take time, that other work on WindowBlinds may take precedence, and that other products may take precedence over WindowBlinds as developer attention is finite. 

What I would not expect to be able to tell someone for whom my software is silently failing:

That might be your wish, but unfortunately, it doesn't work that way. The 0s and 1s have rules they follow. If you configure a system the special, uncommon way you want, a program isn't going to adapt itself to that. It can't. It does what it's coded to do. 

It's illogical to expect software to become aware and change it's programming to fit any given system. It's equally illogical to expect a software company to change its software for one customer's system.

Instead, Support has tried hard to find a way to accomplish what the OP wanted but it just doesn't seem it's in the cards, this time.

Sometimes you just have to say (regrettably), "sorry, we'd liked to have helped you, but we couldn't" as the answer despite everyone wanting it to have been otherwise.

Hi, just checking, did you see the unattended XML I shared here? Drop this file into the root of a Windows 11 24H2 installer image, fire it up in a VM, and you will have an exact duplicate of my install-time settings in maybe an hour tops

I do agree that it's a waste of time for all involved to be speaking in purely speculative terms as we have been, and as we continue to.

We need explicit debugging output for one specific interaction: whatever happens under the hood when one clicks the “Apply style to desktop” button, where WBConfig is (I assume) invoking the WB Service to Do The Thing via whatever IPC/LPC/RPC mechanism Windows uses. Without that information it is impossible to do more than guess, and guessing is a waste of time.

What I am asking for:

1. Use my unattended XML to create a duplicate of my software setup.
2. Add or enable debug logging (i.e. to a text file) around what happens when the “Apply style to desktop” button is clicked in WBConfig. Something is invoking something else there, and debug logging will say what that call is and very likely also why it failed.
3. If unwilling or unable to do (1), tell me how to enable debug logging in the public build of WB and/or share a debug-enabled build with me here so I may try it and report back.
4. Then and only then would be it possible to judge how much work something would take to fix and how many users/scenarios it is likely to affect.

I understand that you have both offered a lot of suggestions, and I am appreciative of that, but from a software-engineering/debugging point of view we haven't tried anything at all. We are at step zero and have been for this entire thread. There are no logs, so how can anyone say anything at all about what is or isn't the trigger and what is or isn't out of scope?

The quoting mechanism is working quite well, therefore no one is making up anything, nor misattributing it.

Please reread the last sentence in reply 27. My reply clearly was to bobj420 the bold font is mine to make finding what I quoted easier for you: bobj420 quoted you [in the small box]. I quoted him [in the large box] and changed his font to bold to emphasize the fact [to you] that I'm quoting him.