Maybe I'm missing something here, but let me put $.02 in anyway.
TOAST reuses entries. If a toasted value is unchanged on UPDATE (i.e. the toast pointer didn't get replaced by a new value), the new tuple points to the same toast slices as the old. If it is changed, the current transaction DELETEs the old toast slices and INSERTs new ones (if needed).
If your session has a transaction snapshot that protects the old toast slices from being vacuumed away, you are fine. Even under READ COMMITTED (that is why it uses that other visibility, so they don't go away when the concurrent UPDATE commits and rather behave like REPEATABLE READ).
At least that is what the code was intended to do originally.
Regards, Jan