mano, ta dificil de tu entender esse bagui. casos que você não passou ou não sabe dizer uma solução mais eficiente chama de "malabarismo", isso é atitude pequena.
se tu escreveu um código em Java, C, Python ou JS.. e ira gerar docs com doxygen, a imagem de doxygen (ex, da greenbone) não vem nenhuma linguagem de script além do shell original. (e nem deveria vir para manter a imagem limpa)
se usar o proprio python do projeto para fazer um script de filtro você vai precisar criar um dockerfile só para geração de documentação.
agora, se fazer um script de filtro escrito em uma linguagem compilada e montada dentro do volume sem precisar fazer nenhum docker build.
docker run --rm -v $(pwd):/app -w /app greenbone/doxygen:latest doxygen
dentro do Doxyfile
INPUT_FILTER = ./doxfilter
e denovo, se fez um script em python com features de 3.10 e a pessoa tem python 3.9 não ira rodar. agora além de existir pouca atualizações de features em C++ é padrão fazer checkagem se o recurso existe e é muito mais facil porque você verifica muitos de uma vez só.
Calma aí, amigo, só tô tentando ter uma conversa agradável. Entendi o ponto, mas acho que você é que não pegou o meu. Se já tem um ambiente de desenvolvimento, o Python faz parte dele, então nem precisa de Docker pra isso, certo? Ou você já vai ter uma imagem de build, então não precisa de outra só pra um script.
Mas, olha, vai em frente se você acha que faz sentido. Já dei minha opinião. E, se ainda quiser insistir nessa ideia maluca, considere Go ou D, que permitem esse seu binário independente, seja lá o motivo, mas de forma muito mais ágil. D usa a STL de forma nativa, e a standard library do Go é uma delícia de usar.
E de novo: a questão da portabilidade nem é tão robusta quanto parece quando há dependências dinâmicas.
Escrever scripts em C++? Pra mim, é como fazer em Java ou C#.