Changing a type that forbids arithmetic to an arithmetic type is technically source-breaking in C++ — it can be detected by SFINAE — but the practical compatibility risk is low. If the architecture vendors are comfortable changing the behavior of __bf16, I think Clang should go along with it, and in that case there’s no reason to treat them as formally different types with different manglings. We should use the new mangling when introducing a new type on an architecture, but ARM’s request to continue using the vendor-extension mangling on ARM seems reasonable.
The implementation options for the actual arithmetic are basically the same as they were for _Float16: we can use native support on architectures that provide it, and otherwise we need to promote/demote to (presumably) float. When we’re doing the latter, we should probably use excess-precision arithmetic by default, but we can provide controls to disable that and force immediate promotion/demotion around individual operations.