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 — a regular 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 stage deeper. This adjustments the Merkle root, which adjustments the output key (P2TR handle) by way of the BIP-341 tweak formulation.

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 change into invalid? Does the spender must reconstruct it with the Tapret leaf hash included within the Merkle path?

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