Take a look at the new implementation of the Shared Bridge and how tokens are gotten from the legacy bridge, https://github.com/code-423n4/2024-03-zksync/blob/4f0ba34f34a864c354c7e8c47643ed8f4a250e13/code/contracts/ethereum/contracts/bridge/L1SharedBridge.sol#L115-L136
Now this function calls https://github.com/code-423n4/2024-03-zksync/blob/4f0ba34f34a864c354c7e8c47643ed8f4a250e13/code/contracts/ethereum/contracts/bridge/L1ERC20Bridge.sol#L63-L69
Case with this implementation is the line
This automatically means that all fee on transfer tokens sre not supported, cause now while transfering the funds, as far as the fee is charged the difference between the former balance and the new balance is not going to be the same, and as such this attempt to transfer the funds would always revert, note that protocol cant also specify a lower amount to be sent due to the check that ensures the whole balance is sent.
Now whereas protocol does not work currently with FOT tokens, there are tokens that exist that could have their implementations be update to support fees, effectively breaking protocol if that were to happen.
Funds are potentially stuck in the ERC20 bridge, also core functionality is broken, being that transferFundsFromLegacy() wont work for these tokens.
In as much as the aim of transfering these tokens from the ERC20 bridge is to clear the bridge of the tokens in it, then the finalization check could be changed from balanceAfter - balanceBefore == amount and instead implemented as a check that ensures that IERC20(_token).balanceOf(address(legacyBridge)) == 0 after the transaction.
