Я думал об этом. И не только я - поэтому был сделан кодогенератор FTCG.
Проблема в том, что система Android и так по своей природе неповоротлива. Да ещё и выполняется на слабых устройствах. А описанный тобой подход добавит ещё больше тормозов.
Конечно, возможны варианты. Например, благодаря FTCG мы можем использовать несколько типов данных: как в компоненте FileOperations - отдельные точки для строки и для готового объекта, либо одна точка, которая сама определяет тип поданных на неё данных (в некоторых компонентах так и сделано). И здесь вообще нет ограничений - что автору компонента больше нравиться, так и делает. Я в этом плане для себя точки не ставил - предполагал, что пакет будет ещё значительно перерабатываться, в т.ч., в плане сокращения количества типов данных, передаваемых между компонентами. Просто пакет ещё далеко не сформировался.

Ещё одна трудность - вот ты сделал компонент, который работает с файлом в виде строкового пути. А теперь представь, что существует некий тип данных, который не имеет строкового представления - те же InputStream/OutputStream и их наследники, Canvas, Bitmap и т.п. Эти объекты могут даже не создаваться автором компонента - он их получает готовыми из других объектов. И как с ними можно работать кроме того, чтобы в одном компоненте давать ссылку на них, а в остальные - передавать. Максимум - это как можно чаще каждый раз создавать/уничтожать, что нерационально.

Наверно. Если для него есть командная строка, то можно добавить аналогично BlueStacks. Только для автоматического определения его наличия на компьютере и добавления в список доступных эмуляторов он должен прописывать себя в реестре. Иначе в лаунчер придётся просто добавить параметры и кнопку типа "Установить в genymotion" (можно в лаунчер вкладки добавлять для разных таких эмуляторов).