Type coercion using xsd equivalents for native JSON datatypes leads to unexpected results

Input:

{
  "@context": {"foo": {"@id": "http://foo.example", "@type": "http://www.w3.org/2001/XMLSchema#boolean"}},
  "foo": true
}

Compacted against:

{
  "@context": {"foo": {"@id": "http://foo.example"}},
}

Results in:

{
  "@context": {"foo": {"@id": "http://foo.example"}},
  "foo": {
    "@type": "http://www.w3.org/2001/XMLSchema#boolean",
    "@value": true
  }
}

There might be an extremely fine semantic distinction here, but isn't {"@value": true} supposed to be semantically equivalent to {"@value": true, "@type": "http://www.w3.org/2001/XMLSchema#boolean"}? I understand that "true" can be coerced to a boolean, but true is already a boolean. There seems to be a disconnect between the native datatype and the @type, where native JSON datatypes have an implicit @type corresponding to xsd, but explicitly applying this type can do weird things with compaction depending on whether or not your context includes the @type in the term definition.

Start with the input, compacted context, and result shown in the issue; compare native JSON boolean handling with explicit xsd:boolean typing. Done means resolving whether these forms are semantically equivalent and agreeing on the expected compaction behavior for the JSON-LD 1.1 specification.