Information

25.08 03:21:46 [Server] INFO Server version: 1.14.4-R0.1-SNAPSHOT git-Paper-162 (MC: 1.14.4)
25.08 03:21:46 [Server] INFO EssentialsX version: 2.17.1.13
25.08 03:21:46 [Server] INFO PlaceholderAPI version: 2.10.3
25.08 03:21:46 [Server] INFO LuckPerms version: 4.4.1
25.08 03:21:46 [Server] INFO Vault version: 1.7.3-b${env.TRAVIS_BUILD_NUMBER}
25.08 03:21:46 [Server] INFO Citizens version: 2.0.25-SNAPSHOT (build 1718)
25.08 03:21:46 [Server] INFO EssentialsXChat version: 2.17.1.13
25.08 03:21:46 [Server] INFO EssentialsXAntiBuild version: 2.17.1.13
25.08 03:21:46 [Server] INFO EssentialsXSpawn version: 2.17.1.13

Server log:
https://pastebin.com/wUywSkRW
ess debug: https://pastebin.com/f5wiaQ8f

EssentialsX config: https://gist.github.com/CaszGamerMD/526a6341df77339397d20228a3721edc

Details

Description
perms for nick.color and nick.format don't actually do anything

Steps to reproduce
have perms for nick.color/format set

Expected behavior
allow access to all colors/formats

sounds good, i'll try right now.

(-) removed the false perm, and nothing changed,
rebooted after perm change, no change

Essentials will only check all of those individual color permissions if they're set (positive or negative) /somewhere/ in your permissions plugin. If the /ess debug output still looks the same as your original output (and my set 2 output) then they're still set somewhere. Could you generate a new debug output to check?

So, using the following versions:

[23:01:27 INFO]: CONSOLE issued server command: /ess version
[23:01:27 INFO]: Server version: 1.12.2-R0.1-SNAPSHOT git-Paper-1594 (MC: 1.12.2)
[23:01:27 INFO]: EssentialsX version: 2.17.1.13
[23:01:27 INFO]: LuckPerms version: 4.4.1
[23:01:27 INFO]: Vault version: 1.7.2-b107

It seems like this issue might occur when intentionally negating permissions with a wildcard. For the purpose of this experiment we'll set up two permissions groups:

[PERMISSIONS SET 1]
> lp group default permission list
[23:02:31 INFO]: [LP] default's Permissions:  (page 1 of 1 - 3 entries)
[23:02:31 INFO]: > essentials.nick (true)
[23:02:31 INFO]: > essentials.nick.color (true)
[23:02:31 INFO]: > essentials.nick.format (true)

[PERMISSIONS SET 2]
> lp group default permission list
[23:07:56 INFO]: [LP] default's Permissions:  (page 1 of 1 - 4 entries)
[23:07:56 INFO]: > essentials.* (false)
[23:07:56 INFO]: > essentials.nick (true)
[23:07:56 INFO]: > essentials.nick.color (true)
[23:07:56 INFO]: > essentials.nick.format (true)

Note the intentionally negated essentials.* node in the second group.

When using permissions set 1 (no wildcard negation), the command is successful in replacing the colors and setting the nickname as seen in the debug log: https://gist.github.com/triagonal/8d0777f9b8636fb05b73430939aa0fa9

However, when using permissions set 2 (with wildcard negation), the color and format checks pass, but then the negated permissions cause all of the chat and format enum checks to fail, causing none of the color codes to be replaced and subsequently failing the alphanumeric check. This can be seen in the debug: https://gist.github.com/triagonal/e4615d1d8ce4223e9b42d81e1e109e07

So, TL;DR: Intentionally negating permissions with a wildcard like essentials.* or essentials.nick.* even when granting essentials.nick.chat|format will cause the individual color formats to not be replaced and then trigger the alphanumeric check failure.

The fix should be to remove any kind of wildcard negation of Essentials permissions in your permissions plugin.

(hope I didn't screw any of that up)

i found it, and fixed it.
i would still think nick.colors/formats would hold priority in that, but i fixed my issue

Closing now since it's fixed, and the core problem appears to be with how permission plugins handle negative permissions rather than with Essentials itself. So it's unlikely any changes can/will be pursued here.