this is hard unfortunately. some problems:
mechanically, beancount doesn't put a cost basis on the augmenting legs of transfers. colloquially, it doesn't transfer the cost basis with the transferred lots.
more seriously, it's not clear if there's a generally-useful automatic booking method for this. Algorithms like FIFO make sense for sales because they result in some intuitive results of selling older assets. But a transfer isn't a sale, so why would you necessarily want to be transferring the older assets? In the realm of crypto, if you assume that wallets can be separated into exchanges and cold storage, then you might argue that in general you want to use your selling booking method for sales and for transfers from cold storage to exchanges (which may be presumed to be in preparation for sale), but the inverse booking method for transfers from exchanges to cold storage. I actually have something like that coded up, but it involves so many assumptions it is not clear to me that it would generalize to enough use cases to be justified.
there's also the problem that coding it up requires hacking up some really delicate bits of the internal booking methods in beancount and there's a lot of concern about changing those for this use case.
i've used my own hacked-up version of beancount to calculate taxes but i am not happy with it and have yet to find a satisfactory solution.