One avenue to look at would be the scenario where three bitcoin confirmations are needed, but only two confirmations have occurred. I remember Patrick explaining this in his Blockchain Brad interview about a year ago. At the time, Patrick called it Greedy Stateful Data, where the data is always stored, so that the height of Block Collider’s chain may include the same BTC block references many times. However, these BTC block references may change. Let’s assume that the same BTC block is referenced in twenty consecutive Block Collider blocks. We can call this BTC Block A. But then, on the twenty first Block Collider block, another valid BTC block is referenced. We can call this BTC Block B. During a Borderless transaction, Block Collider may not necessarily have to wait for the Bitcoin network to confirm the most current block. Instead, Block Collider could require thirty five consecutive BTC Block A blocks (without a competing BTC Block B block) before it will allow a transaction to execute on Borderless. This could resolve the issue of waiting for the final BTC block to confirm, but wouldn’t resolve extreme network congestion on native chains.
This being said, there are probably a lot of details that I’m not aware of that should be answered by someone from BC Core.