scoped context does not work for aliases of `@type`

Sometimes, it makes sense to have a JSON property be an alias of @type/rdf:type, and interpret the value in a particular vocabulary. E.g.

{
  "@context": {
    "@base": "https://example.org/ont/",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "owl-type": {
      "@id": "@type",
      "@type": "@vocab",
      "@context": {
        "@vocab": "http://www.w3.org/2002/07/owl#"
      }
    }
  },
  "@id": "myProp",
  "owl-type": "ObjectProperty"
}

to generate the following triple

<https://example.org/ont/myProp> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2002/07/owl#ObjectProperty>.

Unfortunately, it does not work, and generates instead (the object is different):

<https://example.org/ont/myProp> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://example.org/ont/ObjectProperty>.

I get the result above in the [playground], and with all the implementations I have tested (Rust, Ruby, Jena, PyLD), so although I didn't check the algorithm yet, I assume this is a compliant behevior, but I find it both annoying and counter-intuitive. The reason I find it counter-intuitive is that "regular" properties (as opposed to an alias of @type) work as expected. For example, if you replace "@id": "@type" with "@id": "rdf:type" in line 6 of the example above, you get the expected result (again, in all tested implementations).

Should this be considered as a spec bug?

Start by checking the JSON-LD processing algorithm against the playground example and compare the expected and actual triples. Determine whether the current behavior is compliant and, if not, define what specification change would be needed.