These are FAQ items discussed by the MFA subgroup for possible addition to the FAQ or a future reworking of that document.
It is, but this is a poor chocie in most cases because it ties internal practices to an externally-imposed definition that may create problems down the road. Within the enterprise, there can be constraints on MFA usage due to issues such as a need to fail open during outages, special treatment for VIPs, very long "Remember Me" bypass policies with solutions like Duo, and so on. Maintaining flexibility is usually paramount, while federated interoperability requires more strict adherence to externally defined rules.
Serving both ends is difficult or impossible with a single <AuthnContextClassRef>, so the advisable course is to create a local value in the organization's own URL namespace and use that value when interacting with internal or contracted services, reserving support for the REFEDS MFA profile value for federated use. While in many cases this may be trivial because they may be handled identically by the IdP, having the second value allows them to be treated differently if they have to be.
This is related to the previous question. It is common in an enterprise for most "rules" to be broken under all sorts of exigent circumstances when there are documented or informal processes in place to deal with them. MFA deployments are no exception to this rule. As a specific example, there are sometimes union contracts that make it impossible to impose requirements for the use of personal devices in order to carry out essential work functions, and the workarounds for this can often involve compromising on sound practices for the use of MFA to even outright exemptions to its use.
These cases should NOT be hidden behind the expression of the REFEDS MFA profile <AuthnContextClassRef> when issuing assertions. The kinds of give and take that exist within an organization do not scale beyond the boundaries of the systems under that enterprise's direct control. As such, it is important that the REFEDS MFA profile context class only be included when actual successful completion of MFA has occurred within a reasonable time frame. If in doubt, the value should not be asserted.
It is a direct violation of many federations' participant agreements and rules of the road to ever assert anything that an IdP operator knows to be false, and configuring support for the MFA profile context class without actually configuring the necessary controls to ensure that this is always appropriate would be such a violation.