Есть такой вариант. Да, хорошо делать так, чтобы для заявленного
библиотекой функционала, достаточно было включить её заголовок, без
ожиданий, что пользователь включит недостающее сам. Но, бывало, я переделывал свой же код, например, переопределял структуры обмена данными, упрощая их и уточняя под задачи библиотеки с той целью, чтобы заголовок библиотеки не раскрывал слишком много внутренностей, пространств имён и лишних, не нужных пользователю функций.
Слишком много открытых внутренностей - вредно, особенно, когда программист не один.
Бывало, переобъявлял одни и те же данные и внутри передавал через приведение типа. Просто для того, чтобы не светить родительскую библиотеку. Тут думаю, ООП бы хорошо зашло.
Повторю мысль. Если в заголовочный файл приходится включать много заголовков других библиотек, я задумываюсь об упрощении и переобъявлении структур данных. Это вредно с точки зрения сопровождения кода, так как при смене в родительской библиотеке, придется вручную править дочернюю, но по крайней мере ассерты для обнаружения изменений расставляю.