One of the stated goals for R4B is to be as backwards-compatible as possible.
Gino, from Microsoft, identified the following change which was unexpected given this aim:

In R4B, both ActivityDefinition.subject[x] and PlanDefinition.subject[x] have picked up a new additional choice type.
In R4 they could be only CodeableConcept or Reference, but in R4B they can now be canonicals.
This will pose a challenge for R4 clients that could otherwise interact with these resource types. They should be able to continue writing valid instances, but if an R4B client has submitted data with the new choice type, these R4 clients will likely choke on it.

I think the safest thing to do would be to back out this unnecessary change to ActivityDefinition and PlanDefinition in R4B and leave the change for R5.

Originally raised and discussed on Zulip at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/R4B.20compatibilty/near/269299318