Дарова!
Можно как-то заставить их сотрудничать? )
Или может есть какаянить альтернатива?

"или подождать когда это сделаю я" -  Ждать долго то?
Я так и думал что придется перегружать его. Еще думал что возможно как-то это можно сделать иначе...

Как это понимать?!
Думаете уровень моих знаний ниже?

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

надеюсь, этих разъяснений достаточно?)

niXman, предлагаю эксперимент:)

вводные: наша вфс будет иметь предопределённыую структуру пути (урл) - http://ftp://username:userpass@hostname/path/to/somefile. при получении пути, начинающегося с "ftp://", метод QAbstractFileEngine::create(...) создаст нам экземпляр класса FtpFileEngine (назовём его так).
разрешается: пользоваться любыми костылями в меру фантазии.
запрещается: модифицировать классы с префиксом "Q", функции с префиксом "q" и макросы с префиксом "Q_"
требуется: одновременно может быть открыто более одного фтп-соединения (сессии), но фактическое соединение для каждой сессии должно быть уникальным - т.е., для любой отдельной сессии перечисление каталога (FtpFileEngineIterator) и файловые операции (FtpFileEngine) должны происходить с использованием одного и того же экземпляра класса QFtp - без разрыва соединения между операциями. при завершении работы с сессией соединение должно быть разорвано и отпущены использованные ресурсы (внешних признаков окончания сессии нет - вероятно, их потребуется определить по использованию ресурсов).

какие будут идеи?

к сожалению, задачка с фтпфс более простая, чем задачка с зипфс, которой я сейчас мучаюсь. наверное, есть какой-то обходной способ упростить мои мучения, но для этого мне нужен свежий взгляд и пинок под зад
сегодня услышал мнение, что QAbstractFileEngine уже не покрывает потребности нативной QFSFIleEngine. но сделать с этим до 5.0 они всё-равно ничего не могут (помним про source compatibility?)
прискорбно, конечно, но выбора нет - костыли и патчи...

зы. не нужно на "вы" - мы же здесь в одном котле

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

причина не называлась, но по косвенным признакам могу сделать предположение, что какие-то новые идеи также приходится реализовывать через костыли (мап/анмап, например)

моя задача - сделать фвс, прозрачную для приложения (в идеале любого на кутэ). т.е. в моём случае QFile("file.zip") - это файл, но QDir("file.zip") - это папка. это победил уже - написал пару патчей. но проблема в том, что без контекста невозможно определить что же требуется от пути: QFileInfo("file.zip") - это файл или папка? сейчас это файл и сделать его папкой можно лишь так: QFileInfo("file.zip/"), но тогда файлинфо будет возвращать другие filePath() и т.п., чем QFileInfo("file.zip")...
буду всю поездку ломать над этим голову...надеюсь, что-нибудь придумается

zipfs я уже реализовал через ZipFileEngine (пока только на чтение). вот только хочется "прозраности"...
но я в принципе согласен - если за время поездки ничего умного не придумается, придётся отказаться от "прозрачности" и сделать что-нть вроде регистрации расширений для различных вфс (.zip, .iso и т.п.). это создаст массу неудобств и боюсь, придётся тогда клепать какие-нибудь промежуточные костыли для прозрачности файловых операций