A bit of tracking this down:

It's a Safari bug, not a general WebKit-family bug; it doesn't happen in Chrome. It also doesn't happen in the Safari Technology Preview, so presumably it's something that'll go away on its own if we ignore it. (I don't have the macOS beta installed, so I don't know where the Safari in it falls on this spectrum.)

We only insert ☁ if there's literally no text content in the paste destination, and it only persists after the paste if the cite was the entire contents of your paste.

If there is content already in the paste destination, pasting just-a-cite has the interesting effect of resetting the cursor position to the start of the document, instead of leaving it where it is.

Yeah, just tested in Safari 10.0 preview (in Mac OS 10.12 Beta 7); nothing gets inserted (instead of a black cloud), and the cursor gets moved to the start of the surface.

Presumably the preferred action would be to put the contents of the <ref> into the surface instead?

The current behavior if you're pasting more than just a solitary-ref seems to be to convert it into not-a-ref. i.e. literally pasting in foo^[1].

I can see a bunch of UI arguments here...

• We could make it be [1] for consistency with the in-other-text case.
• We could make it be the contents of the other ref, as a shortcut for duplicating the ref and editing it.
• We could make it turn into a shortcut to reusing the existing ref and immediately editing it, though people might not expect it to do that.

I like option 2. Option 3 would not be possible if the target (rather than source) reference already has contents (without obliterating the contents), and Option 1's consistency is high but its do-what-the-user-actually-wants seems low. :-)

Right now this is consistent in Safari 10+ and Chrome, but old Safari has (had?) an issue. Perhaps we should down-scope this to just the make-Safari-9-consistent bit, and spin out the "what would be nice?" item to another task?

How much usage does Safari 9 have, relatively speaking? I'm doubting this is a high priority issue.

Well, trusting https://analytics.wikimedia.org/dashboards/browsers/, it seems Safari in its entirty has a 2.8% share on our sites this month, and only 29% of that is Safari 9 or below. So 0.812% of our overall browser usage is this.