Unicode normalization forms: when ö != ö

Some time ago, a very weird issue was reported to me about a Nextcloud system. The user uploaded a file with an o" on a SMB share that was configured as an external storage in the Nextcloud server. But when accessing the folder containing the file over WebDAV, it did not appear (no matter which WebDAV client was used). After ruling out the usual causes (wrong permissions, etc...), I analyzed the network traffic between the WebDAV client and the server and saw that the file name is indeed not returned after issuing a PROPFIND. So I set some breakpoints in the Nextcloud source code to analyze if it is also not returned by the SMB server. It was returned by the SMB server, but when the Nextcloud system requested more metadata for the file (with the path in the request), the SMB server returned a file not found" error, which lead Nextcloud to discard the file. How can it happen that the file is first returned by the SMB server when listing files but then the server suddenly reports an error when requesting more metadata?

Special characters must be second only to time, dates, and timezones when it comes to weird behaviour in code.