Obviously, it should make sure that the capability passed to free has full authority over the block first, or else it may end up vulnerable to confused deputy attacks.
But certainly with CHERI you could recover some optimization opportunities. For example, the block length can be derived directly from the pointer, which could make it easier to lookup the parent pool. And CHERI pointers preserve some bits for application pointer tagging, making it easier to implement typed allocations.
However, you still have to be careful. CHERI provides spatial safety, not temporal safety--double frees, dangling pointers, etc--so you may not want to reuse the application-visible portion of a block for bookkeeping purposes. Similarly, ASLR still retains much of its benefit, as does Rust--static enforcement of temporal safety, not spatial safety, is the principal value-add of Rust (spatial safety in Rust primarily comes from the library, not the language per se).
You need a CHERI OS on a CHERI CPU running software compiled with a CHERI aware compiler.
Doesn’t Rust also provide buffer overrun protection, without needing a special OS or CPU instruction set? Isn’t it a better ROI to rewrite the software on Rust, and not have to change anything else?
Can the same benefit be achieved by replacing CHERI CPU with a virtual machine runtime, or building support in LLVM IR?
No, because there’s still quite a lot of (inevitable) Unsafe Rust code floating around, and the compiler can’t protect these from memory-related errors. In fact there are some ongoing discussions and progress to support CHERI in Rust: