Currently, link params act as the initial value of a custom property in the embedded page. This interacts with @property by just overriding the initial value specify in the rule.

This feels a little awkward! At the time I wrote this draft, I wasn't thinking about custom env(), but now that I am (in the context of Mixins), I think that's actually a better solution. I think this solves several issues at once:

• Custom env() are kinda intended to solve the "global var()" problem better anyway, and link params are a perfect match for "global variable".
• This avoids any conflict with @property.
• It won't conflict with @env either - link params will live in the global scope, higher than (and thus automatically overridden by) any @env rules used anywhere in the sheet. (Probably these are in the exact same scope as JS-set custom envs; I imagine we'll expose them in the JS API when we define that, as global custom envs that exist at page load.)
• You can still use them like a var if you want (allowing them to be overridden in subtrees), by just setting :root { --foo: env(--foo); }.
• This solves the hand-shaking problem in a natural way, without us having to do anything special. If you want to pay attention to a --foo link param, you'll write env(--foo) in your sheet. If you don't, you won't. If you're already using env(-foo) on your own, without expecting a link param, you'll have already set an @env in the appropriate lexical scope, which'll shadow the link param and protect you from it. There's no chance of a param setting a var higher in the tree than you expected, so you get an attacker value rather than an unset variable. Etc. Literally the only way to be attacked is to use env(--foo) without ever setting @env --foo in your page, which is a trivial error that'll be caught by your DevTools anyway.

So, unless someone comes up with a good reason to do something else, I'm going to change the draft to make them custom envs, instead.