Segwit workaround safe to use?

[landabaso]

I've observed this library does not fully support Segwit.
However, it's still used in important projects such as BlueWallet.

I decided to open an issue so that we can discuss about possible workarounds and typical questions that may arise.

In the BlueWallet project they do some "tricks":

https://github.com/BlueWallet/BlueWallet/blob/master/class/wallets/abstract-hd-electrum-wallet.js

They inject a script structure in each utxo to account for Segwit.
From the comments in the code, this works when using Native Segwit and Nested Segwit addresses only:

// this is a hacky way to distinguish native/wrapped segwit, but its good enough for our case since we have only
// those 2 wallet types
if (this._getExternalAddressByIndex(0).startsWith('bc1')) {
  u.script = { length: 27 };
} else if (this._getExternalAddressByIndex(0).startsWith('3')) {
   u.script = { length: 50 };
}

Is it there anything that we should wary about doing that?
Can this still be used in transactions that have a mix of p2pkh and segwit (native and nested) inputs? (not adding a script structure in P2PKH utxos and adding length:27 or 50 for native and nested utxos, respectively?)

Also, in the target utxo they add 3 bytes for some reason (only if bech32, not if p2sh-p2wpkh).

if (t.address.startsWith('bc1')) {
  // in case address is non-typical and takes more bytes than coinselect library anticipates by default
  t.script = { length: bitcoin.address.toOutputScript(t.address).length + 3 };
}

Does anyone know what do they mean by non-typical address?

In general, will this trick break things if using taproot?

Thanks!

[Overtorment]

segwit workaround is safe to use, the best way to verify it is to write unit tests for your own code to check that fee was calculated correctly (bluewallet has this).
for taproot you might need to recalculate the numbers.

PS. a handy tool: https://bitcoinops.org/en/tools/calc-size/

[landabaso]

Thanks.