I'm confused. I may be completely misunderstanding what you're saying, Chris, but here's my understanding.

In my simple brain I thought that "the @href on the referencing element" that also has a @keyref is _always_ irrelevant unless the definition of the key name fails to resolve to a resource. It's a fallback. That's what "the language in the spec about falling back to the href on the referencing element" means. It's at 2.1.3.4.3.2 "Using keys to address DITA elements":

If both @keyref and @href attributes are specified on an element, the @href value must be used as a fall-back address when the key name is undefined, and should be used as a fall-back address when the key name is defined but the key reference cannot be resolved to a resource.

I'm not sure where the generalization "the reference wins" comes from. Several references are in play here. The @href on the referring element 'wins' only if the reference specified in the key definition fails.

In your example above, the key name "website" is set to the @href reference given in the effective <keydef> or <topicref> that defines that key name. If you want to change what it points to, you include the topic that contains that <xref> in a map in which some other definition of the key name "website" comes first. If you move it to a map in which the key name "website" is not defined, or if for some other reason that key name does not resolve to a URI, then the <xref> resolves to href="http://www.oasis-open.org" (the @href in the referring element) as a fallback.

A reference to that key is a reference to null. If you include the topic with your example <xref> in a map in which the key name "website" refers to null, then there is no link at that location in output. Further, if empty elements in that topic use @keyref with that key name to pull in content, then in this map where the key name "website" refers to null those elements are dropped from output. I don't remember, but I bet there was discussion of use cases for this behavior.

The language here (2.1.3.4.3.3 Processing key references) clouds the distinction between the referring element and the references (@keyref, @href, etc.) that the referring element contains. This is how the spec reads now:

When a key definition has no @href value and no @keyref value, references to that key will not result in a link, even if they do contain an @href attribute of their own.

The word "they" is ambiguous. This is how I think it should read:

When a key definition has no @href value and no @keyref value, references to that key will not result in a link, even if the referring element contains an @href attribute of its own.

If I'm out to lunch here, I expect to be corrected in short order, but I think I'm understanding this correctly.

/Bruce