>Вот именно от этого и хотят избавиться

Это не возможно: если либы нет, то кто вместо неё работу выполнять будет? Другая либа? Ну так поздравляю - от чего ушли - к тому и пришли. Бандлованная либа всё равно есть либа, просто бандлованная. Она всё равно потребляет память. Причём несколько раз - один раз потребляет либа в системе, а другой раз - бандлованная либа. Собрать 2 либы, одну для 32 бит, другую для 64? Ну так и было и есть сейчас. Можно ли обойтись без 32-битных реализаций? Можно - сгенерить 32-битную либу, которая будет переключать проц в 64-битный режим и обратно на каждом вызове API, а дальше пробрасывать в 64-битную либу. В вайне есть реализация этого. Вполне можно сделать дополнительное имя ABI, и иметь 2 венсии каждого пакета с либами, один с пробросом, а другой с реальным 32-битным кодом, для большиинства пакетов такие stubы будут намного легче, чем добавочные 32-битные реализации. И проблема решена без всяких высокопроблемных методов, вроде бандлования.

Бандлование - это то, что несёт в себе проблемы, но оно порождено нижележащими проблемами, которые бандлованием пытаются просто замести под ковёр, сказав "как же меня достало делать мою работу, вот, подавитесь, беру и бандлую, теперь я свободен от пакетного рабства и что хочу со своей копией - то и делаю, никто мне не указ, это наоборот теперь я всем указываю, сколько памяти докупить и какая версия зависимости будет в моей программе", вместо работы с апстримом по внедрению в апстримные версии всех необходимых интерфейсов и обновления своей программы под изменения в апстриме. В основном эти серьёзные проблемы такие:
* разработчик - лентяй и пофигист. Правильное решение - уволить такого работника и нанять нового.
* апстрим - упёртый баран. Правильное решение - создать свой форк, перевести на него сообщество, а баран пусть в свою отставшую никому не нужную версию рогом упирается.