Ambiguous Error Codes from FileManager.createDirectory When Intermediate Path Is a Regular File

On Darwin and swift-corelibs-foundation, FileManager.createDirectory(atPath:withIntermediateDirectories:attributes:) fails when an intermediate path component already exists as a regular file, even if withIntermediateDirectories is true. Apple's documentation does not fully specify which NSError code should be returned for this condition, leaving developers uncertain whether to expect NSFileWriteFileExistsError, NSFileReadNoSuchFileError, or another value.

This ambiguity is compounded by cross-platform differences: swift-corelibs-foundation has historically reported different error codes for the same filesystem conflict, and exact error domains or names may vary by OS version. In automated deployment or build pipelines, a script may assume a directory tree exists while an earlier step created a regular file at one of the intermediate paths, causing directory creation to fail unexpectedly.

Given that the underlying POSIX errno may be the only stable signal across platforms, which error code should production code handle as the primary case? Is there a documented contract for FileManager that specifies the exact NSError domain and code for an intermediate regular-file conflict? Should developers inspect the underlying errno instead of matching against Foundation error constants?