Now that is interesting. Thanks, it's infinitely preferable to using & and brackets.

I know and use the unary + trick for disambiguating, but I would never have thought to try that here. I would have been worried that applying unary + to a function returning a list might have resulted in a scalar context.

Now my (mostly rhetorical) question is why does that allow the parser to recognise the function name as a sub returning a list, as opposed to a comparator function being passed?

I suspect the answer may lie in the deparse output that shows the undisabiguated function name being passed as a string constant, despite that doing so requires the parser to see the token uniq as a bareword and silently convert it to a string constant, which it shouldn't have as strict is in force.

I am convinced that there is a bug here. I think that sort should either take a bare block, or the address of a function, if the comparator is supplied.

Or possibly a string variable or constant that is the name of the comparator function, though I'm not personally fond of that option.

Under no circumstances, especially with strict in force, should it silently coerse a bareword function name into a string constant.