Some older languages had/have a clear separation - syntactic and semantic - between subroutine and function!

Perl doesn't, but explains the terminology for people coming from there.

perlfunc describes builtin "functions" in CORE::

Most can be replicated with with pure Perl when using prototypes , so those "flat list arguments" don't apply in these cases.

Other built-ins can't be replicated because they require special parsing of their arguments.

The " mathematical function" part is misleading, because Perl's subs can have side-effects, like altering passed or global or closure variables.

Compare that to languages like Haskell which do their best to be side-effect free like mathematical functions.

Operators in perlop are indeed built-in functions with special syntax, context and precedence. You can replicate $a+$b*$c with add( $a, mul( $b, $c ) ) and in some docs you'll find function like built-ins called "operators"

The goal you seem to have is to define Perl in Lisp'ish way, where everything can be derived from a small set of axioms.

I doubt that's possible, because the creators cared more about DWIM than orthogonality.

Perl has loads of influences from C, bash, sed, awk and Lisp and tried to combine them in an "organic" way to make people coming from those ends feal like at home.

Those features were not implemented in a clean canonical mini Perl ...

EDIT

... and there is no language definition like ECMA.

The best possible outcome you can achieve is probably a language definition for 98% of Perl combined with a long list of exceptions.

One simple example: built-ins like map and grep can be replicated with

 
sub name(&;@) {
   my ($code, @list) = @_;
   ...
}

# then called
name {BLOCK} LIST;
[download]

BUT having a return inside the BLOCK will lead to a very different result, hence gone the orthogonality.