Comment 21 for bug 1647485

Regarding the workaround patch from comment 17, I should note that the workaround involves replacing all whitespace in the NVMe model or serial string with underscores. This matches what is done for the by-id symlinks for scsi, ata, and all other buses. However, another possibility is instead of underscore-replacing the whitespace, it is 'encoded' by replacing it with literal '\x20' (i.e. the characters '\', 'x', '2', '0'). This is done for whitespace in some other symlinks, e.g. LVM and UUID.

Because all existing bus types use underscore replacement already for their symlinks, I think it seems extremely likely that underscore replacement will be used upstream for NVMe as well. However if they don't, then this workaround would conflict with upstream, meaning the workaround would generate symlinks different than upstream udev without this workaround; to use the example from the description, this workaround would create:
/dev/disk/by-id/nvme-XYZ_Corp_NVMe_drive_SERIAL -> ../../nvme0n1
while upstream (if the literal-encoding approach is used) would create:
/dev/disk/by-id/nvme-XYZ\x20Corp\x20NVMe\x20drive_SERIAL -> ../../nvme0n1

until my patch to upstream is either accepted or rejected (and some other fix used), it's impossible to tell with 100% certainty what approach upstream will decide on.