I'm unsure whether that's exactly what Richard says. I think that it's the other way around in his explanation: the second SCS occurs as part of the reference binding, and the wording should stop pretending that it's the other way around. In my own wording, I would compare it with the rule of a "proxy". Below is a more elaborate explanation. Long story short: In my opinion, both SCSs and the user-defined conversion (which are constituent of a UCS) occur within the reference binding, with the "UCS" being the proxy!

Let me note that this is conceptually the same thing as with "list initialization sequence": There are only three ICSs: standard, user, ellipsis. What list initialization sequences (and reference bindings) do is to use a proxy ICS to represent themselfs to the ruleset. But some rules look through the proxy. For list-initialization, some rules even pretend that the ICS itself is a list-initialization. The analogy in our case would mean that we consider the UCS as being the reference binding, but not the second SCS.

Richard's wording is a good proposal as it fixes this, but IMO in addition we need to specify explicitly in [over.ics.ref] that any special casing based on that a reference binding was done applies only to the last SCS to occur in the sequence.

You're right; Richard did provide a wording change that makes the SCS part of the reference binding, and acknowledged that an alternative is to make the reference binding part of the second SCS. In any case, I think we all agree that some wording change is needed.

We already have [over.match.viable] p4

Third, for F to be a viable function, there shall exist for each argument an implicit conversion sequence (11.3.3.1) that converts that argument to the corresponding parameter of F. If the parameter has reference type, the implicit conversion sequence includes the operation of binding the reference, and the fact that an lvalue reference to non-const cannot be bound to an rvalue and that an rvalue reference cannot be bound to an lvalue can affect the viability of the function (see 11.3.3.1.4).

For a standard conversion sequence, there is only one standard conversion sequence to talk about.
For a user-defined conversion sequence, there are two standard conversion sequences, so we should say that the binding is part of the second one.
For an ellipsis conversion sequence, there is no standard conversion sequence.