Do you intend something like Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"\r\nLink: <https://www.w3.org/ns/activitystreams>; rel="profile" by “ActivityStreams with the ActivityStreams profile”? In that case, we’d have no problem with interpreting the profile parameters as idempotent, I guess?
I’m not suggesting to replace your proposal. Instead, I’m suggesting to extend the “MAY” behavior to make it applicable to other RDF syntaxes. (You may not like extending the requirement for backward compatibility with something new, though.)
While the “Hey this isn’t ActivityPub” semantics sounds nice for making some decisions on compatibility considerations, I believe we need a requirement clearer than just “be careful” as a security precaution, which should be fool-proof, and yet I suppose that rejecting anything that doesn’t explicitly support ActivityPub is not what everyone wants.
Content-Type and profile may not perfectly fit the purpose of expressing the server’s intention, but I suppose that it would still be a reasonable compromise to assume the responsibility of servers that presents the Activity Streams media type to ensure a minimum level of integrity of data they publish. In that case, we might at least want to update the security considerations of the IANA registration, though.
By the way, regarding security requirements in FEPs in general, the discussion in the following topic may be interesting:
(Not that I have an opinion on it. I’m linking to it merely for an informational purpose.)