user47827: On the bitcoin-dev mailing list Russell O'Connor stated:

There is a bug in Taproot that allows the same Tapleaf to be repeated
multiple times in the same Taproot, potentially at different Taplevels
incurring different Tapfee rates.
The countermeasure is that you should always know the entire Taptree
when interacting with someone's Tapspend.

Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree? If Taproot was (hypothetically) redesigned today would it address this bug and how?

user47827: 
Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree?

It isn't necessarily a bug that a Taproot tree allows a leaf script to be repeated on multiple levels of the tree on construction and even if it was there would be no way to address this as the Taproot tree is only (partially) revealed at spending time. However it presents a malleability vector if at spending time the same Tapleaf can be spent from at multiple levels on the tree.

If Taproot was (hypothetically) redesigned today would it address this bug and how?

Yes if it was redesigned today it would at spending time require signing the entire Merkle path rather than just the Tapleaf. This doesn't prevent a Tapleaf from being repeated on Taptree construction but would prevent the same Tapleaf being spent from on a different level of the Taptree.
ghost43 stated on IRC:

If the Merkle path to the Tapleaf was signed it would not be interesting whether there is a duplicate Tapleaf in the tree. The issue is that as the Tapleaf path is not signed, if the Tapleaf is duplicated anyone with knowledge of the Taptree can "rebind" the spend to refer to the other matching Tapleaf. It is a sort of malleability. If the path to the leaf was signed this would not be possible.

Thanks to ghost43 and AJ Towns for answering this on IRC.

47827: <p>On the bitcoin-dev mailing list Russell O'Connor <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021452.html" rel="nofollow noreferrer">stated</a>:</p>
<blockquote>
<p>There is a bug in Taproot that allows the same Tapleaf to be repeated
multiple times in the same Taproot, potentially at different Taplevels
incurring different Tapfee rates.</p>
<p>The countermeasure is that you should always know the entire Taptree
when interacting with someone's Tapspend.</p>
</blockquote>
<p>Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree? If Taproot was (hypothetically) redesigned today would it address this bug and how?</p>
 47827: <blockquote>
<p>Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree?</p>
</blockquote>
<p>It isn't necessarily a bug that a Taproot tree allows a leaf script to be repeated on multiple levels of the tree on construction and even if it was there would be no way to address this as the Taproot tree is only (partially) revealed at spending time. However it presents a malleability vector if at spending time the same Tapleaf can be spent from at multiple levels on the tree.</p>
<blockquote>
<p>If Taproot was (hypothetically) redesigned today would it address this bug and how?</p>
</blockquote>
<p>Yes if it was redesigned today it would at spending time require signing the entire Merkle path rather than just the Tapleaf. This doesn't prevent a Tapleaf from being repeated on Taptree construction but would prevent the same Tapleaf being spent from on a different level of the Taptree.</p>
<p>ghost43 stated on IRC:</p>
<blockquote>
<p>If the Merkle path to the Tapleaf was signed it would not be interesting whether there is a duplicate Tapleaf in the tree. The issue is that as the Tapleaf path is not signed, if the Tapleaf is duplicated anyone with knowledge of the Taptree can &quot;rebind&quot; the spend to refer to the other matching Tapleaf. It is a sort of malleability. If the path to the leaf was signed this would not be possible.</p>
</blockquote>
<p>Thanks to ghost43 and AJ Towns for answering this on IRC.</p>
