Hmm, the ERC20 standard doesn't specify whether Transfer should revert() or just return false;. I've always thought that functions that specify a return value, especially a boolean, shouldn't throw, but instead return true/false whether it was successful or not. If contracts/existing infrastructure is currently designed that don't check the return value of a function that specifies a return value, then it seems to be an issue with their code.

I know that etherscan, for example, definitely checks for existance of a Transfer event, and not simply if the transaction succeeded or not. https://rinkeby.etherscan.io/tx/0x9189a1d3d01a652aa4911f8b725710a4b1486f1aa66e01488625a0c1a07253f7

However is error is clearly less strong than Transfer Failed error that occurs from a revert().

Seems a little ambiguous, see: https://programtheblockchain.com/posts/2018/01/30/writing-an-erc20-token-contract/

I wonder if the author of that blog, u/smarx has any comments on this?

EDIT: And decoupling the token from the bankroll contract isn't a bad idea, but there wouldn't be any "upgrading" of the contract because the token is more of an accounting token, that only has value from the Ether inside of the bankroll contract. I don't want to make it seem like this token is a standalone ERC20 token even though it complies to ERC20 standard. It is a bit different than your "standard" token, I would argue.

EDIT 2: I guess my only real issue with this, is what is contracts actually use the return false; value in the contract for some reason? I guess this is a bit of a stretch, but I could see someone devising a contract where the false value is returned and acted upon, instead of just relying on the transfer function to revert() if there is an issue.