taproot – Does inserting a Tapret dedication leaf invalidate the present management block for different script paths in RGB?

I am researching how RGB makes use of Taproot commitments (Tapret, LNPBP-12) and ran a switch experiment on testnet: 64a14551…c20b6b.

The RGB consumer output reveals the state anchored at tapret1st:64a14551...c20b6b:1 — an ordinary P2TR output on-chain.

My understanding is that Tapret inserts an unspendable 64-byte OP_RETURN leaf into the script tree at depth 1, shifting present scripts one degree deeper. This modifications the Merkle root, which modifications the output key (P2TR tackle) through the BIP-341 tweak method.

Two questions:

1. If Script_A was initially at depth 1 (single-leaf, empty Merkle path within the management block), after Tapret insertion it strikes to depth 2. Does the unique management block turn out to be invalid? Does the spender must reconstruct it with the Tapret leaf hash included within the Merkle path?

2. For the reason that Merkle root modifications with each new Tapret dedication, does RGB all the time derive a contemporary P2TR tackle for every state transition — even when the interior key P stays the identical?