I created a subtask (MDEV-8822) for the documentation shortage.

Aliases for function arguments is a feature request, so the issue has been switched from Bug to Task.
Looking at the SQL standard, I am not sure it should be implemented. If I read it right, it says that a function call can indeed have AS ... clause, but it would be AS UDT type rather than AS alias.
Not having UDT types in the current implementation is one thing, but using the syntax for something different is another.
However, I'm never sure I understand the standard correctly, so I'll keep it open till serg says his word.

As far as I can see, AS UDT only applies to stored routines, not to built-in functions. AS xxx in built-in functions is non-standard and doesn't serve any useful (or useless, fwiw) purpose.

In UDFs it's non-standard and very non-conventional and inconsistent. But it's a historical feature that we preserve for compatibility reasons. I don't see why it should work for other (not UDF) functions, if it's useless there. Especially, as it might conflict with future extensions (like AS UDT).

I agree on this, I was just suggesting to treat it as a warning instead of a syntax error.

By the way, as I commented in MDEV-12877, there is a problem about the "type" of a function result. For instance, some of the new JSON functions return a String but somewhere MariaDB test to know if this is a JSON item or not. Actually I don't know what criterium they use but it fails in some case.

In the JSON UDFs, I am using the alias to test this and I don't know what I could use if this was not kept in future versions. For instance, using alias is what enables a function like JSON_MAKE_OBJECT to make a JSON object from values retrieved from a table, the alias being the column name. For instance:

SELECT JSON_MAKE_OBJECT(name, title) FROM employee WHERE name = 'Smith';

Returns:

{"name":"Smith", "title":"Engineer"}

I don' think this can be achieved with a native function.