Fake Bool operation with OSL shader
This is a partial solution. For simple scenes it'll work fine, but more complex setups will run into problems very quickly.
/*
 * Checks if, for this ray, the object is already inside the named object.
 */

    shader Intersects(   
        string Container = &quot;&quot;,
        output int Intersects = 0
    ){
        if(trace (P, backfacing() ? -N : N )) {
            string name;
            getmessage(&quot;trace&quot;, &quot;geom:name&quot;, name);
            if (name == Container) {
                Intersects = 1;
            }
        }
    }

This shader returns 0 if there is an intersection with the named object, and 1 if there isn't.
It is adapted from a script by Secrop found here, as well as the Dipper script Robin Betts suggested to me from an earlier answer here.
I essentially just combined the two, while stripping them both down to the bare minimum. I'm not entirely sure, but I believe there is a bug with the getmessage() command. It appears to often do nothing, rendering much of the related logic unnecessary/redundant/ineffective. For instance, in Secrop's script, neither the backfacing() check, nor the material:index check(!) appear to do anything at all.
As far as I can tell, there are no such redundancies in this script.
That being said, it's entirely possible, I'm missing something here. Certainly, adapted from Robin's script, the call getmessage(&quot;trace&quot;, &quot;geom:name&quot;, name); works just fine, so I don't know where the issue lies.
Workflow:
Here is an example setup.


Note, the deformed cutting cube also interacts with the sphere, to close it back up. Without that, the sphere would be missing some walls and it'd render more like a shell, rather than an enclosed surface.
Currently the setup basically has the cube cut out a piece of the sphere, equivalent to the Boolean &quot;Difference&quot;. Using different variations of this node setup, you can also get it to work like various other Boolean operations.
Limitations:

The materials here are completely unchanged. As you can see, it may get confused in certain situations. Suzanne looks, like she partially is made of glass or something. Given how she's entirely made of diffuse materials, this certainly isn't supposed to happen. This must be the cube material getting confused about the location of the inside of the sphere.
Here you can see the same scene but with the roles of the cube and the sphere exchanged (just flip the mix shader input for both).

Note, Suzanne does not touch the sphere. If the script worked perfectly, Suzanne's chin would be yellow throughout. It shouldn't be view-dependent, but strictly about whether a mesh is inside another.
There may be ways to fix these issues, but I'm not sure how.
At any rate, that's the reason why this won't be the accepted answer.
The reason I put it as answer anyway is because for relatively simple setups, this will likely already work perfectly.
One simple workaround, that may, however, not always be feasible (depending on your situation), is presumably to have several such masking objects, none of which, I assume, may intersect, all of which affect the meshes they intersect in a uniform way. (For instance, if the setup renders glass walls for one object it intersects, it ought to do so for all objects.)
This next one I'm not quite sure whether there is an issue here:

In this variant, I made the cube, now clear glass, cut out a piece of the now diffuse sphere. To close the sphere, in the intersecting area, the cube generates a diffuse shader matching the sphere. Consequently, those faces will not be glass shader ones.
Now I'm not entirely sure. This would depend technical details. But does Cycles count this situation as escaping the glass to hit a diffuse mesh? Or will it think it was diffuse all along, making it more like the interface between air (vacuum) and this diffuse surface?
I'm not entirely sure it will actually make a difference, but I think it might: Namely in the case of total reflection. If Cycles thinks this is a glass-to-diffuse transition, the right setup, I think might cause total reflection, rendering the diffuse surface entirely invisible behind the internal reflection of the glass. If it rather considers this a case of having been diffuse all along, things will go wrong when internal reflections become important.
Unfortunately, for my ultimate use case, that would definitely be an issue. I'll have to see whether it works there.
Finally, I'm less concerned about it working with Volume shaders, but I did a few quick tests and it actually appears to work fine... To a point. It's certainly easy enough to make something look super weird.