The @ symbol is a valid character for a filename. However it's a reserved character in an URI, and thus shouldn't be used for filenames which end up as part of an URI.
See RFC 3986 Section 2.2 for reserved characters and 2.3 for unreserved ones.

Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved. These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.

So, the media manager does act correct because it tries to make the filenames safe to use in an URL.
Closing this as expected behavior.

Interesting. Well, somebody should tell these guys:
https://developer.apple.com/library/ios/documentation/2DDrawing/Conceptual/DrawingPrintingiOS/SupportingHiResScreensInViews/SupportingHiResScreensInViews.html#//apple_ref/doc/uid/TP40010156-CH15-SW1
and this guy:
https://imulus.github.io/retinajs/

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

Interesting indeed. So Apple hacked a feature into their iOS which is basically against an RFC as I understand it.

I reopen the issue then since it seems to be a requirement for Apple devices.

As explained in #4995 mailcloak would create unwanted results of we allow this.

I mentioned this in the emailcloak thread referenced, but the RFC says to use percent encoding. So the media manager so do that to URI reserved characters. Whether that would work, is another question. But it IS the expected way to handle weird characters in filenames.

What about using the urlencode() function?
In joomla.filesystem.file there could be a function like:

    public static function makeURL($file)
    {
        // Remove any trailing dots, as those aren't ever valid file names.
        $file = rtrim($file, '.');

        return urlencode($file);
    }

which is then called to save the uploaded file in the filesystem without "weird" characters:

    $file['name']     = JFile::makeURL($file['name']);

...or is called by makeSafe() in the first place.

If it is taken serious, the encoded filenames are for "internal" use and should be decoded with urldecode() when displaying the filename for the user, or building them into something else.

No.

Moving to Needs Review so a Maintainer can decide if this should changed or not. Thanks.

The PLT has decided not to implement this change and keep the current behavior. Thank you for your contribution.