Fixed in 2.49.5
So... I've run into a tricky regression going from 2.49.3->2.49.4. I say it's tricky because it involves other 3rd party software. Normally, I wouldn't bother bringing 3rd party software problems to another 3rd party... except that only 2.49.4 has this problem and downgrading immediately fixes it. I don't want to stay on 2.49.3 forever, so I'm trying to report it anyways.
I use the default Windows taskbar hiding on my primary display, Start11 is not "enhancing" it. On my secondary display, DisplayFusion(11.0.5) is creating a taskbar substitute as it is far superior to the Windows secondary taskbar. In 2.49.3, this works fine... although it doesn't work well if I let Start11 "enhance" the taskbar and replace the hiding behavior with the fadeout instead of default slide.
In 2.49.4, Start11 is somehow tricking DisplayFusion into thinking that the taskbar is reserving space from the screen bounds and that the working area is no longer the entire screen. DisplayFusion's taskbar on the other screen ends up moving upwards away from the bounds by the same amount the taskbar normally takes and then reserves the space above that for its own taskbar... which takes 2x the space from the working area of the desktop.
When the taskbar is hidden, things look normal. When the taskbar slides up, DisplayFusion moves its taskbar up by the same amount. It's evidently reading some size from the real Windows taskbar to figure out the space to reserve... and 2.49.4 is now messing that up somehow.
Again... this feels weird bringing this problem up with Stardock... except that the move from 2.49.3 to 2.49.4 is the cause. Which is super strange because I asked Start11 not to "enhance" the taskbar. But it's obviously doing something new with this version.
Open the spoiler for a GIF of the issue: (okay, never mind... spoiler tags don't even work on the forum for some reason)
Windows 11 Home 24H2 26100.2605