I managed to understand my problems. When packages are built with conda, they dynamically link to @rpath/libc++.1.dylib, but when they are built using the normal compiler they are linked against /usr/lib/libc++.1.dylib. These are incompatible builds of LLVM's libc++, so when an istream or ostream are handed from one library to the next we get horrible surprises that are challenging to understand.
The solution is to make the local CMake build absolutely identical to the conda build. This also means that you must install the binaries to get them to execute correctly, and I'm uncertain if this will impact the ability to run the debugger easily.
My updated build steps are on the following GitHub gist:
https://gist.github.com/oursland/e1dc94 ... e6c573d711
I'll work on getting the changes prepared in a PR so that the conda weekly builds can be made for ARM64, but I think getting the Homebrew tap realigned may prove more valuable for rapid development.
On Linux, it took all of an hour to get the ci/Dockerfile updated and a .devcontainer/ configured for a standard VS Code development environment complete with compilation and interactive IDE debugging. On macOS it's taken a week to get it built, and I'm uncertain if the artifacts are suitable for interactive IDE debugging.