Extending APFloat with one more IEEE float format isn’t really a significant change; it’s minimally invasive, and there isn’t really any stability commitment because APFloat is only exposed in the C++ API.
If you want an LLVM IR type, I think we’d want a more serious discussion of how we actually want to handle this sort of construct. There’s a significant stability commitment for LLVM types, and supporting code generation is a significant amount of code. The existing implementation is designed under the assumption that new floating-point types are added rarely, but machine learning seems to be leading to a proliferation of new floating-point types.