It's probably better if it shouldn't. It's generally better to prevent passwords from containing characters that can't be entered on a decent proportion of devices you may encounter.
Emojis are particularly problematic because new ones keep being added which require OS upgrades, and you might find yourself needing to log in from another device that just doesn't support those emojis yet.
Also it's not like Unicode makes everything easy. For example, you have to remember to normalize the password before hashing. Otherwise something as simple as "ñ" may be a totally different byte sequence depending on which device you're using.
It is no longer realistic to pretend that only ASCII exists and try to get away with that.
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
>>> "ñ".encode("utf-8")
b'\xc3\xb1'
>>> "ñ".encode("utf-8")
b'n\xcc\x83'
For way too much information on this, see: https://www.unicode.org/reports/tr15/
Even a lot of Unicode-aware code written by a developer aware of at least some Unicode issues often fails to normalize properly, most likely because they're not even aware it's an issue. Passwords are a case where you need to run a Unicode normalization pass on the password before hashing it, but, unfortunately, if you're already stored the wrong password hash fixing it is rather difficult. (You have to wait for the correctly-incorrect password to be input, then you can normalize and fix the password entry. This requires the users to input the correctly-incorrect password; if they only input an incorrectly-incorrect password you can't do anything.) I'd suspect storing a lot of unnormalized passwords before learning the hard way this is an issue is the majority case for homegrown password systems. You hear "don't roll your own crypto" and think reaching for a bcrypt or scrypt library solves it, but don't realize that there's some stuff that needs to be done before the call to those things still.
Emoji weren't officially supported until Unicode 6.0, though there are a subset of current emoji (less than a quarter) that work on Windows 7 in practice.
Meanwhile the current standard is 15.1.
There's no security or convenience necessity whatsoever for supporting emoji in passwords, but inconsistent OS support is an excellent reason against it.
There's quite a bit of convenience, and some concomitant security, to using emoji in passwords. Emoji are high entropy code points that are easily visually distinguishable across most language boundaries. A "short" password of just emoji is going to have way higher entropy and be way harder to brute-force/rainbow table than any equivalent "length" (by visual character count) ASCII-only password. That should go without saying. The fact that huge boost in entropy also comes with a massive benefit in how quickly a user can glance at their password and know that they typed in right/wrong often faster than they could if forced to build a line-noise password is a huge bonus. (Related to why Windows 10 experimented with Picture Passwords and a lot of Android users use some form or another of Gesture PINs.)
That said, I think the real solution is of course to eliminate passwords altogether (and yes Passkeys are our best hope right now). But saying that we have to stick to ASCII for passwords because that's a lowest common denominator for keyboards is very much like saying that we should stick only to passwords that you can T-9 on flip phones or send in an SMS or that passwords shouldn't really be longer than 8 characters just in case some Unix system needs to use the old DES-based crypt() function or that passwords shouldn't contain quote marks, semicolons, or percentage signs because those might be SQL injection attacks and you might have some PHP apps that are vulnerable to those. You are letting silly technical lowest common denominator bugs stop you from increasing security for the median/mean user.
(I've spent about 6 years of my career running video streaming services... People watch a lot of video on TVs, it turns out, so you probably don't want to let them put these sorts of characters into their passwords when they sign up on mobile or computer devices.)
I'm not trying to invalidate your personal experience. You've seen a lot of good social reasons users probably "can't" be trusted with emoji passwords. but at a purely technical level the number of OSes in 2023 that can't pop up an emoji keyboard if asked is incredibly slim and the number that can't have an emoji keyboard in user space as a software addon is even slimmer. If a device doesn't support at least UTF-8 encodings in 2024 that's an entirely different can of worms (and probably a bad sign for the security of the device itself).
Both the Xbox and PS4+ have emoji keyboards. Apple TV has an emoji keyboard. Almost every version of Android TV and Samsung Tizen and Roku and Fire OS and ….
Go ahead, tell me you have a lot of customer support problems that you don't want to support emoji in passwords. That I can believe. I can't believe it's a technical problem in 2023. Emoji are universal enough now in 2024 that OSes are broken if they can't send/receive emoji and don't have some sort of keyboard to input them. Even if we are still turning off the emoji buttons on password fields because we don't trust users to do it for social reasons rather than technical ones.
As I said, it's not about support for emoji as a class.
It's about support for specific emoji. Different OS's are on different versions of Unicode that support different sets of emoji. The older versions don't support the newer emoji.
So yes, in 2024, it would be incredibly easy to create a password using an emoji on your up-to-date Mac that simply can't be entered on your Android-based TV you purchased 3 years ago, because it doesn't have that emoji even though in supports emoji in general.
So no -- it's not for social reasons, it's very much for technical ones.
And trying to implement a rule like "emoji are allowed but only the ones that were present in Unicode 6.0" is incredibly confusing and opaque for end-users, so it's a better experience just to not allow emoji at all.
Additionally, I'm not sure that supporting full Unicode access (or even just the hundreds (?) of emoji) using a D-pad as an input device would be a good UX.
The upper layer might change now and then, to give a veneer of modernity. But just like Windows being built on 90s technology, the stuff underneath could be even more ancient.
Would it, really?
P0 would probably be "10% of our customers can't submit an order." Or "20% of our vendors are experiencing 404s."
We're taking OP's word for it that FedEx doesn't allow certain characters as passwords (actually, from the description, it seems more like FedEx only allows specific characters which is even worse). If either of those are true, it is most certainly a defect. Whether FedEx treats that defect as an emergency is up to them I guess. I'm saying many modern companies would.
You originally said "Weird password issues don't count as broke." I think this might just be a case where we have to "agree to disagree".
If I read it right it sounds even worse. Fedex allows the characters and then random stuff just breaks.
It is much preferred to get a simple "only english alphabet and numbers please" warning message when you are trying to set the password than not getting any warning and then things breaking.
It never makes you feel very confident in an institutions security when they can't even figure out how to get a username/password to work properly on their systems.
I meant broke in the sense of "if it ain't broke, don't fix." If there are over 300 microservices running code, connected to mainframes running code that was originally from the 80s, but they occasionally have password issues - the risks caused by trying to fix it might be greater than it's worth.
That doesn't mean FedEx can't do a better job telling people not to use special characters - or detecting if their current password contains them and forces a password change.
And we ended up where the thread originally begin "FedEx may have the worst and least secure digital platform for a major company."
Besides that is horrible! There should be 1 microservice which deals with passwords, the authentication one. Everything else should just get a token attesting that the user is authenticated (or not).