Nice release - deterministic replay isn't easy - I still need to go back and pull our implementation forward to match the new features in the core framework. I'm not sure if you've seen Basis, but we're somewhat "competing" in the same space. You're all in on Rust, we're C++ with bindings to other languages (eventually). I don't see this as a bad thing - more tools in the space is a win, eventually the industry will settle on something better than ROS.
Having maintained something similar myself, how has your experience been with exact determinism in C++? C++ compilers tend to be a bit of a free-for-all when it comes to bit determinism, whereas the rustc folks are very good about spending the design time to preemptively avoid many of the issues you'd need workarounds for in other languages.
My goal is determinism specifically around message timings/execution in replay. We don't currently advertise runtime determinism, we also don't promise fixes for determinism in your code. For message timing, the algorithm should be stable - it generates a timeline for when messages should be executed by each message handler, and will pause further executions to wait on handlers that "should have" finished, but haven't due to running too slow. Ties are broken by the handler name or data source name. I wrote a bit about it here https://basisrobotics.tech/2024/09/02/determinism/ but didn't go deep into the implementation. If your own code isn't deterministic you will have differences, but this eliminates the biggest classes of nondeterminism when running tests (threading timings, message handling races).
I don't think Copper claims to offer more than this either, but I can't speak for them.
