How to mitigate accidental/unwelcome IRI expansion?

Dear all,

When learning Activity Streams 2.0
<http://www.w3.org/TR/2015/WD-activitystreams-core-20151006/>, I discovered
that certain @ids were vulnerable to being mangled during expansion. For
example, the absolute IRI tag:search.twitter.com,2005:593895901623496704
gets expanded to
http://www.w3.org/ns/activitystreams#tagsearch.twitter.com,2005:593895901623496704.
(JSON-LD playground link
<http://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%22http%3A%2F%2Fwww.w3.org%2Fns%2Factivitystreams%22%2C%22%40id%22%3A%22tag%3Asearch.twitter.com%2C2005%3A593895901623496704%22%2C%22%40type%22%3A%22Create%22%2C%22url%22%3A%22http%3A%2F%2Ftwitter.com%2FKidCodo%2Fstatuses%2F347769243409977344%22%2C%22actor%22%3A%7B%22%40id%22%3A%22id%3Atwitter.com%3A2993982541%22%2C%22%40type%22%3A%22Person%22%2C%22displayName%22%3A%22Kid%20Codo%22%2C%22url%22%3A%22http%3A%2F%2Fwww.twitter.com%2FKidCodo%22%2C%22image%22%3A%22https%3A%2F%2Fsi0.twimg.com%2Fprofile_images%2F3664410292%2F1d75c213a572873bf6797c5591475da5_normal.jpeg%22%7D%7D>
for
complete example)

Is this a problem that others have come across before? Is there any sort of
standard advice to work around absolute IRIs being mistakenly interpreted
as relative?

An approach I came up with is to “unmap” the offending terms, like:

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    {"tag": null}
  ],
  "@id": "tag:search.twitter.com,2005:593895901623496704",
  "@type": "Create",
  "url": "http://twitter.com/KidCodo/statuses/347769243409977344",
  "actor": {
    "@context": {"id": null},
    "@id": "id:twitter.com:2993982541",
    "@type": "Person",
    "displayName": "Kid Codo",
    "url": "http://www.twitter.com/KidCodo",
    "image": "
https://si0.twimg.com/profile_images/3664410292/1d75c213a572873bf6797c5591475da5_normal.jpeg
"
  }
}

But this seems kludgy, and I could imagine it having unintended
consequences if other parts of the JSON document actually used the tag
property and expected it to expand to
http://www.w3.org/ns/activitystreams#tag. An additional weakness of this
approach is that it relies on a human to determine which IRIs “don’t look
right” by examining expanded documents, and that there’s no guarantee that
other IRIs vulnerable to *different* prefix-collisions won’t slip in in the
future.

Please share any comments regarding the above, or advice in general for
dealing with IRIs properly in JSON-LD.

A pre-emptive & emphatic “thank you” for any guidance you can provide,
-Josh Tilles