it’s a bit of a messy situation, yeah… the migration path isn’t entirely clear.
i guess “option 3” is to redefine attachment and tag to be a @container: @list in the @context, which you’re not supposed to do generally. but consider it a willful violation. this effectively “opts in” to ordering for the document.
as discussed also, there is “option 2”, the possibility of upstreaming a normative change to the activitystreams.jsonld context, but this will break old documents that use a single value instead of an array. (if this happens, i’ll withdraw this FEP)
if going with “option 1” to have new terms using the same id as defined by this FEP, then i can see reasons to use both terms in plain JSON, but it is unclear when such a transitional period would end. in any case, you would use orderedAttachment if present and take it to be ordered, or if not present you would use attachment and assume unordered. (i’m not sure how LD handles the same property twice… i’ll play around with it in the playground)
and i suppose there is “option 0” as evan describes on the PR, which is to attach or tag a Collection or OrderedCollection, but this is semantically different than attaching or tagging items directly, and it would also be backwards-incompatible, as it effectively turns these into special collections similar to follower and following.