то есть контроль ошибок уровня "операция х3 почему провалилась"

какой от этого смысл

ну это лучше, чем ничего

можно продолжать запись

а контроль ошибки отдать вызывающему

у вас какая-то аргументация методом доведения до абсурда, так любую концепцию можно втоптать в грязь

нет, у меня просто есть опыт работы с этими абстракциями

у меня тоже

и получаются два разных интерфейса записи

dump который blind без контроля и save который явно файловой системы

потому что
[[nodiscard]]] bool write_data(stream & s) {
  if (!s.write(f1_)) return false;
  if (!s.write(f2_)) return false;
  if (!s.write(f3_)) return false;
  return true;
}
это просто трешовая копипаста кода

возникшая ошибка все равно будет запрошена создателем, для которого s имеет интерфейс шире

зачем я все это писал? чтобы лишние вызовы write которые мгновенно откажут не делать?

вот как-то
void dump(dump_target & d) {
  d.dump(f1_);
  d.dump(f2_);
  d.dump(f3_);
}
чище, не правда ли?

а при попытках развивать стримы с контекстом начинается полная херня, потому что номинальный тип строки зависит от типа контекста, что делает невозможным унифицированную запись

я не могу inner_identifier_string писать в user_output и localized_string писать в xml_data_output

только на нём надо буферы выделять заранее

а он тоже проактор?

Короче, summary: типы int, float и string это тип "семантическое никто", их параметры форматирования - форматирование семантического никто, а типы, несущие семантику, не могут быть перечислены в унифицированном контексте; как следствие - нельзя терять информацию о типе контекста, что означает шаблонную/перегруженную функцию записи и бесполезность унифицированных стримов за уровнем
struct dump_interface<Object> {
   virtual void dump(Object) /*noexcept?*/ = 0;
};

какой-то однобокий взгляд, у вас свои задачи и контекст, у меня свои. Говорить, что раз вам инструмент не подошёл, значит, он никому не нужен - странновато.