It's also worth remembering that there are plans for borrow variables, so however we end up referring to these in parameter lists should work in standalone code. I think it is worth calling that out specifically in "Related directions", because it is a very direct extension of these concepts.
Borrow variables are important; otherwise working with write-through views becomes extremely verbose. I think people will likely be exposed to borrow variables (especially mutable borrows) more often than borrow parameters.
url.pathComponents.insert(prefix, at: url.pathComponents.index(after: url.pathComponents.startIndex))
^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
// vs
ref path = url.pathComponents
path.insert(prefix, at: path.index(after: path.startIndex))
// + "take path"? "endLifetime path"? We'd need to end the borrow somehow.
// A discussion for another time, but worth keeping in mind.
The ref name proposed in the ARC thread is also interesting. I think you could make an argument that the difference between a String and ref String can be made more obvious to a newcomer than the difference between a String and borrowed String; the idea of a "reference" has a somewhat stronger implication that I don't quite have a String, and that this variable is tied to something which exists externally (to be precise - its lifetime is bound by that external thing). You could also argue that it is potentially confusable with a "reference type", which is fair.