Desde que comecei a usar Rust algum tempo atrás, notei um padrão em praticamente todos os projetos sérios: A arquitetura é levado muito a sério.

Projetos como Tokio, Hyper, Mio, Serde, dentre outros levam o design da crate (equivalente a uma "lib) muito a sério. Os mantedores não hesitam em fechar uma issue que pede uma feature fora do escopo. Se a demanda tá alta, criam uma crate específica para isso, que é o caso do Reqwest.

Reqwest é um client http em Rust pronto para uso. Rust é primordialmente uma linguagem de baixo nível, mas com Reqwest você consegue criar um servidor http (ou client) em minutos. Porém existe o Hyper que é uma biblioteca "low-level". O intuito do Hyper é prover ferramentas para você montar outras ferramentas HTTP. Muita gente pediu, ou tentou adicionar abstrações parecidas com o Reqwest, que não foram aceitas, preservado o propósito do projeto.

Detalhe: Reqwest e Hyper são dos mesmos mantedores.

O escopo do projeto é definido, e não foge disto. Fugiu disto? Melhor criar uma ferramenta nova específica para isso. Menos complexidade em código, menos gambiarra (glue) entre camadas, menos responsabilidades, menor build, menos latência, menos gerênciamento de memória, menos bugs, menos dor de cabeça, CI mais rápido... São tantos benfícios.

Em toda a minha vida a parte mais difícil nunca foi codificar, mas entender e criar arquiteturas escalavéis. Por isso gostaria de reforçar que, defina o escopo, para não virar "bagunça".

Uma vez que implementou uma feature que não faz sentido para o projeto, já era. Não se pode simplesmente remover isto. Pessoas criaram ferramentas usando versão "x" que contém esta versão. Remover isso é uma breaking change que exige uma manutenção absurda, fazendo usuários migrar para algo mais estavél e previsível. Um único commit errado já pode complicar a vida de milhares de pessoas, imagina uma feature inteira?

É muito importante considerar esses cenários, como escopo, escalabilidade, se faz sentido, e etc...