On further reflection, what the "policy" was actually about was not that we should forbid users from creating potentially-confusing aggregates themselves, but only that we'd avoid having any *built in* aggregates with this hazard. So maybe I'm overthinking this, and the correct reading is just that we should have a policy against built-in variadic aggregates.
Yes. I think we can assume that anyone smart enough to create a variadic aggregate is smart enough to put ORDER BY in the right place.
It's not the creator who is in danger, though, it's the user of the aggregate function, AIUI. So unless you're saying that anyone smart enough to use a variadic aggregate can be assumed to be smart enough to put ORDER BY in the right place, I don't think this argument holds.
I was one who sent a bug report - this error is not too dangerous, but it is hidden, and difficult to find, if you don't know what can be happen. Same as bug with plpgsql and SQL identifier collisions. If you understand, then you can protect self well and simply. If not, then it is a magic error. So still I am thing so best solution is
a) a warning when detect ORDER BY in variadic aggregates
b) disallow ORDER BY in variadic aggregates in classic syntax, and enable it only in WITHIN GROUP syntax where is safe , btw a aggregates that needs a ORDER BY is better to evaluate different for minimise risk of OOP killer. This is a good solution without any risks.