It really depends on what exactly you are trying to draw and if the result of your intersection is a shape we already handle. For example, if you wanted to render the intersection of 2 boxes, that is easy because the result is a box and Cesium already knows how to draw boxes. You just need to supply the algorithm that produces the intersection. The same is true if your shapes are in 2D because the result will always be a polygon of some form. It would be trivial to do this kind of visualization using the Entity API.
Where it gets non-trivial is the moment you have shapes that we don’t handle, like the intersection of 2 spheres. At that point you need to create custom geometry. That gets you a static shape, but you would need to handle the tracking/updating of the geometry over time yourself. You could go a step further and implement your custom geometry as an Entity plug-in (which as far as I’m aware no one outside of the core Cesium team has done on their own yet), which then lets it directly interoperate with the rest of the Entity API. It’s entirely possible, just not something there’s a lot of doc on yet. Of course even if you did all of this, the next hurdle would be performance, which will be an issue unless you are only talking about a small amount of objects.
Another even more complex solution would be doing it all in the shader, which would eliminate the performance problem (or at least offload it to the video card), but I’m not sure the amount of worked involved or the complexity makes it realistic.
A completely different approach, would be to use translucent geometry, and allow the overlapping of them to produce more opaque shapes. So if you have a red, green, and blue translucent sphere, the intersection is going to be whiter and more opaque. Of course this doesn’t do exactly what you want, but it’s a compromise that incredibly simplifies the problem