Ну а других причин почему так делать плохо я не вижу. Если конечно приложение не подразумевает гонку. Но там все будет явно сложнее.

Скажем sqlite подразумевает открывание файла БД несколькими процессами.

В общем ладно, так делать или иначе, вопрос другого плана.

Меня больше беспокоит неконсистентность std.file.exists.

Кстати, а зачем вообще может понадобиться проверка файла с последующим созданием? Есть же режим r+

тут есть еще большая проблема, что isFile и isDir  выбрасывают ошибку если файл не существует, поэтому обязательно ставить перед ними exists в булевом && и в случае симлинка первая проверка пройдется, а это наиболее частый случай их взаимного использования. Даже если рассматривать поведение exists в отношении ссылки как корректное, то практически это лютая дичь, которую я хз как можно было умудриться сделать.

надеюсь, что это обусловлено техническими причинами, а не чем-то еще.

Например, какой-нибудь кэш. Если файл есть, то открываем и читаем кэш, если нет пересоздаем кэш.

Логично

в общем, как я понял, нужно ловить ошибку открытия файлов.

все равно под разными операционными системами могут быть грабли с правами, чтением и т.п.

Вопрос, а для ди есть какая-нибудь сводная статья\реп\etc с обзором подводных камней? Например, типа такой о го https://habr.com/ru/company/mailru/blog/314804, для js что-то вроде wtfjs https://github.com/denysdovhan/wtfjs и т.п.

Обычно это фатальная ошибка. Можно не ловить специально именно эту ошибку, а просто где-то на верхнем уровне ловить, писать в лог и завершать работу.

в части cli-приложений сепарация ошибок и ситуаций обычно позволяет дать лучший фидбек от программы. Когда она вылетает,  то сразу ясно почему - потому что файла нет, потому что это не файл, или потому что файл есть и это файл, но прочитать его невозможно, либо же все нормально, но ошибка чтения и т.п. Соответственно, исправлять ошибки намного быстрее и удобнее, чем в случае очень общего текста ошибки  "какая-то проблема с файлом %s". Конечно, полные проверки каждого случая сильно зашумляют код и скорее они актуальны только для важных файлов, пути к которым передаются через cli и т.п.

По хорошему, исключение при открытии файла должно содержать информацию о природе проблемы.

Я не видел. Может в duseful есть, но не уверен.

Темные углы D.

логично, разве что наверное могут быть грабли из-за срабатывания  после ошибки, а не до, что может затереть проблемы с резолвингом\канонизацией\обработкой\etc файловых путей. Если в исключении есть путь и его вывести в тексте ошибки, то он может быть совсем не тот путь, который поступил в файловую операцию и который передавал юзер через cli, конфиг и т.п.

Ситуации бывают разные иногда достаточно такого, иногда нет.

ясно, спасибо.