Проверка на ошибки, да. А дать механизм, который бы ошибку предупредил - религия не позволяет?

Я предлагаю оставить проверку ошибок в покое, а при возможности - уведомлять приложения о различных событиях/изменениях состояния как можно раньше. Чтобы (по крайней мере в штатном случае) не молча обрывалось соединение в самый неподходящий момент, когда приложение будет ждать ответ на DNS-запрос пол-минуты (и, соответственно, крутить индикатор ожидания пользователю). В ряде случаев это не поможет - но в большинстве ситуаций - улучшит user experience.

Нет, если на диске вырос relocation, или ещэ как SMART ругнулся - это не повод паниковать и уходить в readonly и нарушать какие-то важные активности пользорвателя. Но это вполне себе повод: 1) уведомить пользователя, что диск не особо надёжен 2) до его решения ограничить незначимый но интенсивный I/O. И уж точно принятие решения, что надо ограничивать и какие меры принимать - дело отнюдь не ядра, а либо самого приложения, этот I/O осуществляющего, либо работчего окружения, держащего общую конфигурацию.

С дисковыми квотами результат тот же - какой смысл загонять приложение в нештутную (даже если  и обрабатываемую) ситуацию? Сидит, значит, пользователь, обрабатывает здоровенный графиечский файл - и вдруг выясняет, что сохранить он его не может - не важно, места нет или приложение/пользователя квотами обрезали. А А обработать прозрачно - религия не велит? Чтобы, допустим, рядом сидящий браузер кэш от недавно просмотренных видео почистил?

И, соответственно, речь не об audio, а обо всём спектре событий - от информации от железа до соообщений, отосланных из пользовательского скрипта.