@levi_jacobs, You are correct, the change in behavior here was in order to fix an issue related to overriding of a Parent Data Type within a nested UDT instance as well as improper behavior related to bindings against the Parent Data Type. For example:
However, in taking a broader look at things, this ended up reaching a bit further into locking out the ability to change it at an instance level, which while perhaps unintended, did work before. With how properties are stored with a tag, I think it is probably better this way, as changing the parent data type of a tag instance would result in a bunch of potentially stale data/properties being stored with the tag object (since it now has a new shape).
There is an open ticket to address the import-with-overwrite to change the tag definition.