13.2.1. Read Committed Isolation Level

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/transaction-iso.html
Description:

I don't understend this text.

'INSERT with an ON CONFLICT DO UPDATE clause behaves similarly. In Read
Committed mode, each row proposed for insertion will either insert or
update. Unless there are unrelated errors, one of those two outcomes is
guaranteed. If a conflict originates in another transaction whose effects
are not yet visible to the INSERT, the UPDATE clause will affect that row,
even though possibly no version of that row is conventionally visible to the
command.

INSERT with an ON CONFLICT DO NOTHING clause may have insertion not proceed
for a row due to the outcome of another transaction whose effects are not
visible to the INSERT snapshot. Again, this is only the case in Read
Committed mode.'

And specifically this part 'the UPDATE clause will affect that row, even
though possibly no version of that row is conventionally visible to the
command.' What does it mean that no version of that row is visible to the
command? Is this visibility related to xmin xmax values? Or does it mean
that the version of the row is not visible because it has not yet been
commited by a parallel transaction?

'If a conflict originates in another transaction whose effects are not yet
visible to the INSERT' - Does this mean that at the moment of starting the
INSERT statement, the parallel transaction has not yet been committed (or
even started after calling the INSERT statement), but at the time of
performing the action with a row in the INSERT statement, transaction 2 has
already committed its changes? Or does it mean that contrary to Read
Committed Isolation Level, uncommitted changes from a parallel transaction
can affect the execution of an INSERT command?

'INSERT with the ON CONFLICT DO NOTHING clause can result in the insertion
of a row not continuing due to the result of another transaction, whose
effects are not visible in the instantaneous snapshot of INSERT' - same
question.

Could you please describe this behavior in more detail?