Of course, who want to do it. This case, by whom having passion to pull Rust into FreeBSD.
I don't think it good thing to divide very limited developers into C/C++ team and Rust team (of course, no one can force which to choose. FreeBSD is a volunteer-based open source project.) and to change minds who are strongly objecting should need "demonstration of efficiency both in performance and maintainability".
For making this possible should need new developers in Rust area.
I'm relatively open for introducing new language, but at the same time, believing that rewriting whole bunch of components at once is impossible.
For this kind of cases, existing codes written in C/C++ (C++ should be a lot more fewer than C, though) and codes added/rewritten in new language (this case, Rust) needs to sanely coexist/cowork.
If the ABI of new language (say, Rust) is stable enough and fit enough well with C, the pain would be relatively small, but forcing
--crate-type=cdylib
now could spoil at least some portions of Rust's advantage, if I understand correctly.
Moving goal clearly avoids creating sane API/ABI within C/C++ parts and Rust parts.
This is because I state "it's too early" and I think demonstration is needed for breakthrough into earlier shift.
Or do you have better ideas to change minds of who are objecting?