When you contacted tech support, did you report a bug or did you use a support token? I assume it was the former or you would have known the outcome, true? If it was the former, you don't say what the discussion, if any, was with tech support. The usual case in such instances is that it is not a bug but a machine issue. Classic examples are issues with data on network shares that might disconnect when in use, or insufficient memory.
For example, you don't say whether the "admittedly large" operations might exceed 1 TB in working space. Keep in mind the guidance in the "Memory" section of the Performance Tips topic:
I once saw an increasing incidence of that error with 9, but it was only on one machine. Doing the same work on other machines didn't throw that error. So I assumed the problem was with storage. I had plenty of free space on SSD and HD, way more than ten times the size of the data I was working with, which indicated that lack of working space was not the issue.
I did recall that when I first configured that machine I had issues getting it to boot and then to load Windows onto the M4 SSD. Something seemed weird depending on which GPU card I inserted. I had ended up installing a less extreme GPU. Over time, that machine also threw errors in plain Windows operation, like copying very large files through the network to load up the HD.
I guessed that the problem might be either a flaky SSD or a problem with the hard disk. Anybody who has gone down that debugging path knows they have a long road ahead of them, since just running sensible diagnostics on very large disks takes a long time, and then swapping them out and reloading the new disk also takes a very long time.
To make a long story short, I did all that, changing SSD and HD and the machine seemed fine. And then when the new disk was loaded up again after a while errors started again, first being noticed in non-Manifold work (a fairly certain indication the problem is not an error in Manifold).
After a few months using other machines, I decided to once and for all figure out what the problem was, being ready to systematically swap out all components with "known good" components right up to the CPU and motherboard if need be, stripping the machine down to the simplest possible configuration and testing the heck out of everything.
The problem turned out to be one of the memory sticks, which occasionally threw errors at certain clock/voltage configurations. It's very high-quality memory but still, it was not totally reliable in configurations that it was supposed to run. Running it at reduced speeds worked fine.
I rebuilt the machine without the weak memory stick using all of the original components which I had replaced, thinking they might have been the problem. All of the problems noted are gone. I can use the more extreme GPU and there are zero issues with booting. I don't see any errors in Windows operations and the "unexpected error" in Manifold operations in exactly those same projects and operations has not recurred. I've been using that machine for over nine months now and it's run flawlessly.
Just saying, the error you report could be a bug in Manifold, or it could be something else. If you are working with tech support, they always keep in mind the possibility of a bug, even though those are rare. But the only way to tell for sure if it is a bug and not a machine issue like I reported above in my case, either a hardware problem, network issue, or an operational (lack of required storage) issue, can require a fairly lengthy exploration of all the details involved and can require very time-consuming trials using different configurations.
One thing you could do that might be easier would be to try exactly the same intersection operations that throw the above error, but do that on a greatly reduced data set on purely local storage (you didn't say explicitly that all work was done locally, so it's not safe to assume that it was....). That will have the advantage of likely excluding storage space as an issue. If an algorithm is flawed (a bug in Manifold), it's likely to be flawed with smaller data the same as with bigger data. Also, working with smaller data goes quicker so it's easier to try different variations to zero in on possible causes.
Note that neither Arc nor Q uses memory as emphatically as Manifold, so they're not really testing issues that might arise with memory or storage when Manifold reaches out to use those resources. Their results don't prove possible hardware issues are not the problem.