Compatibility/Support of old manifest formats

Support Upgrades
1

I am trying to run upgrade on smart-contracts that were deployed still using the ProxyAdmin <=v4 implementation. I still have my manifest file, from several years ago. I detect that there's a change on the information included in a storage slot in the storage layout section of an implementation. Example:

{
            "contract": "Twin",
            "label": "schainLinks",
            "type": "t_mapping(t_bytes32,t_address)",
            "src": "contracts/mainnet/Twin.sol:39"
 }, // OLD

{
            "label": "schainLinks",
            "offset": 0,
            "slot": "203",
            "type": "t_mapping(t_bytes32,t_address)",
            "contract": "Twin",
            "src": "contracts/mainnet/Twin.sol:39"
}, // New

In this particular variable, I've changed t_bytes for a user defined Value (representing bytes32), and included the correct annotation: /// @custom:oz-retyped-from mapping(bytes32 => address).
The upgrade fails, with contracts/mainnet/Twin.sol:40: Layout could have changed for schainLinks (mapping(bytes32 => address) -> mapping(SchainHash => address)).
Notice that for other contracts that inherit from this one, and have their implementation entry in the manifest updated (using the newer details) this error is not thrown. It makes me wonder if this is indeed a manifest-only issue, and during validation the offset and slot sections are required in this particular case (because there's a re-typing).
If so, I would like to discuss some ideas on how could I go about this, making sure the upgrade is still safe, in the cleanest way possible.

:1234: Code to reproduce

Can provide privately if required, but don't think it is strictly required just yet.

:laptop: Environment

Using hardhat v2, openzeppelin hardhat-upgrades v3+ and upgrades-code v1.39+.

As I understand this particular check is performed in upgrades-core. Maybe this is a recent change ?