On peut le porter de façon simple et en utilisant le moins possible les classes dans les libs standard,
laissant simplement à l'utilisateur la possibilité de faire ses classes pour son propre usage. Ainsi, la langage ne devient gros et lent que si l'utilisateur abuse.

Si y a pas la classe std::string et std::vector, c'est même pas la peine d'essayer de faire autre chose que du C

De plus, l'interface avec le C, et même la conversion complète du C vers le C++ étant quasi immédiate, on pourra très vite voir débarquer la plupart des libs (extgraph, genlib, libs kernels standard comme ziplib et graphlib)

Oui, le problème n'est pas là. Le problème, c'est que si on laisse les gens programmer _vraiment_ en C++, alors il faut avoir ne serait-ce, pour reprendre l'exemple précédent, que la gestion des vector : à chaque fois que la taille du vecteur est multipliée par un facteur Q (par exemple Q=2), on est obligé de refaire une allocation mémoire : vu la qualité de malloc, ce n'est même pas la peine d'y penser... sans parler de la RAM gâchée : on peut avoir un tableau Q fois trop grand que nécessaire, donc si on a un tableau de 40 ko et Q qui est aussi faible que 1.2 (l'allocation est d'ailleurs presque 3x plus lente qu'avec Q=2), on perd 8 ko de RAM.
Et c'est pareil avec les string

On serait obligé de refaire la gestion du heap, et il ne faut pas oublier que le fait d'utiliser des string au lieu de char[] amènerait à un code bien plus gros et lent. Franchement, à mon avis, autant en profiter pour faire un vrai langage interprété. Cela dit si tu veux porter g++, c'est pas moi qui t'en empêcherai, hein