МА>В моем понимании никакого принципиального отличия нет — мы используем тот же поток, но с усовершенствованны буфером. Почему отличий нет? Поясню, мы работаем с файлами, выполняем операции чтения/записи, с новым буфером мы будет выполнять те же операции, потому парадигма потока будет применима и здесь. Прежде чем предлагать отказ от старой, неплохо бы озвучить идею нового метода работы с файлами. Тем более у нового буфера будет поддерживаться вся функциональность filebuf за счет наследования от него и перегрузки только нужных методов.

1.НАСЧЕТ ФУНКЦИОНАЛЬНОСТИ А вот и не вся: половина функций будет старой, а половина новой. При этом использование "старых" функций вносит только путаницу, поскольку они воздействуют только на старый "отмерший" буфер, а на состояния нового никакого влияния не окажут. Точно также и с новыми (перегруженными). Вот вам ситуация: разработчик, не имеющий никакого понятия о том, что скрывается под красивой оболочкой родного iostream, выполняет определенный набор действий, причем в этом наборе действий используются в неопределенной последовательности как "старые", так и "новые" функции. Вопрос: что в конечном итоге получиться? Ответ, я думаю, не знает даже разработчик этого "нового" iostream. Стремный получается этот стрим.

2. НАСЧЕТ ПАРАДИГМЫ. Ж. В том-то вся и фигня, что выполняется по сути ограниченный набор функций, для которых(и только для них) создавался новый iostream. Поэтому, если разработчику надо будет что-то еще, то он с легкостью будет использовать стандартный iostream, и не будет пытаться сделать это как см. пункт1. Так-что для исключения пункта 1 и поддержания в нормальном виде пункта 2. необходимо оставить iostream As it is, а там где нужно, пользовать отдельный класс, поддерживающий необходимый набор функций. Так сказать агрегат, дружественный юзеру: пара кнопок и он все за вас сделает. В противоположность монстру, у которого торчит куча отсохших конечностей, и который при этом ведет себя совершенно непредсказуемо.