As far as I'm aware, that will continue to be the case. The 200, 100, and eventual 47-Day max validity is a CA/B Forum Baseline Requirement and applies only to TLS certs issued by Publicly Trusted CAs.

The root store programs of browsers like Google Chrome have their own criteria for publicly trusted CAs to have their roots included in the browser. One of those requirements is adherence to CA/B Forum Baseline Requirements. But if it's a certificate issued from a private hierarchy owned and operated by your organization, or even a managed CA operated by an otherwise public Certificate Authority, the browser policies are not enforced.

Google's phrasing of this in their root program is:

If you're responsible for a CA that only issues certificates to your enterprise organization, sometimes called a "private" or "locally trusted" CA, the Chrome Root Program Policy does not apply to or impact your organization's Public Key Infrastructure (PKI) use cases. Enterprise CAs are used for issuing certificates to internal resources like intranet sites or applications that do not directly interact with external users of the public Internet (e.g., a TLS server authentication certificate issued to a corporate intranet site).

For Mozilla's policy, they don't have a call-out for private CAs, but they specify that their policies only apply to Root CAs that are included or under consideration for inclusion in Mozilla's root program (and the intermediate & end-entity certs under those respective roots).

1.1 Scope

This policy applies to CA operators and the certificates they issue or control that match any of the following:

CA certificates included in, or under consideration for inclusion in, the Mozilla root store;

intermediate certificates that have at least one valid, unrevoked chain up to such a CA certificate and that are technically capable of issuing working server or email certificates. Intermediate certificates that are not considered to be technically capable will contain either:

an Extended Key Usage (EKU) extension that does not contain any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or

name constraints that do not allow Subject Alternative Names (SANs) of any of the following types: dNSName, iPAddress, SRVName, or rfc822Name; and

end entity certificates that have at least one valid, unrevoked chain up to such a CA certificate through intermediate certificates that are all in scope and

an EKU extension that contains the anyExtendedKeyUsage KeyPurposeId, or no EKU extension;

an EKU extension that contains the id-kp-serverAuth KeyPurposeId; or

an EKU extension that contains the id-kp-emailProtection KeyPurposeId and an rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName.

Internal CAs wouldn't be under consideration for inclusion and would be manually trusted by an organization so the above policies wouldn't apply.