I ended up finding it through a disk space visualizer that showed a large folder (the stolen 100GB) in some cache directory. I can highly recommend trying that out. MacOS' inbuilt tools are in my experience inadequate to find what is stealing your disk space (on top of applications being unable to clean up after themselves).
Let me guess, the best engineers are working on iPad/iPhone apps today and MacOS is relegated to code fixes and people building for the "common user" that doesn't know what a drive is
People talk about Snow Leopard being stable but it was riddled with bugs, just take a look at the release notes for all the updates it received over the next year.
I discovered this while trying to restore a docker vm image that was maybe ignored, while not having enough space on the drive to restore it back, because deleted versions still take up space in the system data, even when the trash is emptied.
Nowadays, my daily travails with restarting Xcode multiple times a day to work around bugs (package blahblah is not available) have really worn thin (I mean, Xcode has always had problems, but not THIS bad). Add to that the fact that the "system data" on my mbp now takes up 80% of the space on my SSD (800GB of system data! Even after manually deleting caches and derived data)...
It's like they don't even care about code craftsmanship anymore. And yet their culture of not putting in useful debug messages (because "it just works") persists.
My latest and greatest headache? Some parts of AppKit now directly call [NSApplication _crashOnException:] regardless of the "NSApplicationCrashOnExceptions" setting, and WITHOUT even calling [NSApplication reportException:]. So now you lose the exception entirely and good luck figuring out what caused the crash. Ugh...