Because of the way the router currently works I think this will have to be marked as a known issue.
Unless someone has a solution to propose.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5215.

It would be better to reject a strictly numerical alias as invalid or to append an acceptable character like a ~ to the start of the string to make it valid.

It's a bizarre issue to encounter as a user and the cause isn't immediately obvious. When I first encountered the problem, I wasn't getting a 404 but was instead being redirected to another page on the site which somehow corresponded to that numerical string.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5215.

I confirm the issue: the first character in the alias should not be a figure.
We could prevent this when we check the alias when saving and throw an error.

but this check would have to be done all over in core...

EDIT: it seems aliases are always using
JApplication::stringURLSafe()
So, it "could" be done in the helper itself only.

hmm, thinking further: we DO have the issue also when a date is entered as alias.
This happens when the alias is automatically generated as a date when the title is a non latin utf8 and transliteration is used instead of unicode alias.
We would get for example
2014-11-27-09-55-00

And, when testing in the same conditions as the original post I would get here:
http://localhost:8888/trunkgitnew/article-category-list/239-extensions/2014-11-27-09-55-00.html

=> 404

bad indeed...

A solution could be to change the stringURLSafe($string) in JApplicationHelper to

    public static function stringURLSafe($string)
    {
        if (JFactory::getConfig()->get('unicodeslugs') == 1)
        {
            $output = JFilterOutput::stringURLUnicodeSlug($string);
        }
        else
        {
            $output = JFilterOutput::stringURLSafe($string);
        }

        if (preg_match('/^[0-9]$/', $output[0]))
        {
            $output = '~' . $output;
        }

        return $output;
    }

Changing this method would break backwards compatibility. As @brianteeman correctly wrote, at this moment we can only mark this as a known issue.

As you may have read, I wrote "could".
It would be B/C BUT would prevent creating first level links/url with a figure as first character in the alias, as those work fine.

As the case exists when the alias is automatically created as a date, a solution would at least be to send an alert.

Setting to needs review

@test not reproducible

I tested it with the sample data and I see wrong articles. The first article belongs to the categorie Components ….

Closing as we have a PR here that fix that in a B/C way: #8141

Thanks