Having an additional scalar / bits type that can hold either a float or an integer wouldn’t really make selection that much easier. The current design already allows matching types based on their bit width.
Introducing yet another type to the IR is just going to make things more complicated by adding yet another code path since the pure integer / float paths still need to be handled. It also makes it harder for RegBankSelect to determine where to insert a COPY between register banks.
Also 2 bits for floating-point semantics seems too few. Short types like f8 often vary in mantissa size, exponent bias, NaN and subnormal semantics, so it is easy to have more than 4 variants.
This depends mostly on how and if we decide to represent these types in LLVM IR. But I agree that we should consider making FPInfo 3 bits for future proofing.