Esse dilema é o clássico ponto de virada de qualquer projeto open-source que começa a ter tração. Parabéns pelo alcance da biblioteca!
No caso de sistemas embarcados como o ESP32, onde memória RAM e estabilidade de sockets são recursos escassos, o maior valor da sua biblioteca é justamente a promessa inicial: ser leve, simples e previsível.
Para não perder o propósito, uma boa regra arquitetural é separar o que é "evolução de transporte HTTP" do que são "outros protocolos/camadas":
1.O que pertence ao core: streaming de payload, timeouts bem tratados, suporte a chunked transfer e upload/download eficiente. Isso continua sendo estritamente HTTP.
2.O que NÃO pertence ao core: MQTT e WebSocket são protocolos de transporte completamente diferentes. Colocar MQTT dentro de um cliente HTTP quebra o Princípio da Responsabilidade Única (SRP) e incha o binário para quem só queria fazer um POST simples.
3.Camadas superiores: GraphQL e MCP rodam sobre HTTP. Em vez de embutir essas regras na biblioteca, o ideal é expor uma interface limpa para que outras bibliotecas possam usar o seu cliente como motor de transporte.
A melhor estratégia para manter o projeto respeitado a longo prazo é a Filosofia Unix: mantenha o core minimalista, afiado e focado em ser o melhor cliente HTTP para ESP32. Se quiser suportar outros protocolos no futuro, crie bibliotecas irmãs e modulares.
Quem escolhe uma biblioteca para microcontrolador prefere 10x uma ferramenta pequena que nunca quebra do que um canivete suíço pesado.