Expansion concept "key's term definition" is unclear with compact IRI keys

My use case was to determine whether
{ "@context": { p: { "@id": "e:", "@container": "@list" } }, "p:1": ["", ""], "p:7891": ["dup", "dup"] }
would treat the p:1 and p:7891 as a @list (desired for my use case) or as a @set (undesired, but actual behavior of reference implementations; I have an open issue in jsonld.js for this as I wasn't sure what is correct).

My problem was that I wasn't able to conclude the correct behavior from the ld-json-api spec. I've now been informed that intent is @set, ie. expanded term definitions only use the @id when used in prefix expansion, so that's settled; this report is to explain why I wasn't able to reach the conclusion to maybe improve the spec itself.

The expansion algorithm 5.1.2 clauses 9.5 and 9.6 refer to "key's term definition" and "key's language mapping" without explicitly specifying the algorithm on how the key string is mapped to the term definition, only (apparently) relying on the simple implicit "key string is used as an exact match lookup against the context dictionary". This implicit meaning would suffice if it wasn't for prefixes and compact IRI's, which are justified as a way to simplify repeated term definitions via a generalized pattern.

So this could perhaps be made a bit more explicit, either on 9.5/9.6 or on sections that discuss compact IRI semantics.

As for my use case I can imagine that extending arbitrarily complex expanded term definitions to results of prefix expansions is not without consequences. So my personal ask is to figure out whether there exists

1. alternative way for me to be able declare JSON array members as rdf lists (providing ordering and duplicates) using @context, in a way that the key contains arbitrary specifiers (like 1 in p:1)? Maybe using the @prefix notation or so.
2. potential plans to include this or similar functionality in future JSON-LD iteration? Within a year or two?

Start with the JSON-LD API expansion algorithm 5.1.2, especially clauses 9.5 and 9.6, and the sections on compact IRI semantics. Compare the wording with jsonld.js issue #310 and determine whether the specification needs explicit key-to-term-definition lookup text. Done means the requested behavior and any supported @context mechanism for arbitrary specifiers are clearly documented or the request is closed with a rationale.