You're saying the project's maintainer is deliberately misrepresenting mrustc's goals in order to prevent malicious interference by the Rust community? Both of those seem very unlikely to me and I can't see anything in your message to provide support for those claims. I see no reason not to just take things at face value here.
Rather than being afraid of interference, the reason that the mrustc author is so careful in their wording is that nobody has ever bothered to define what it means to be a "compatible" implementation of Rust, which is a semantic and legal hurdle that the implementation in the OP will have to clear. In a more concrete sense, mrustc can't currently be a compatible implementation of Rust, because (by dint of lacking a borrow Checker) it accepts more programs than rustc does (arguably it's fine to accept strictly fewer programs than rustc does and still be called a compatible implementation).
Notably, mrustc is a Rust compiler in the sense that it is able to compile valid Rust code. It does not provide a guarantee that it will reject invalid input. The user is on the hook to work out themselves through some other mechanism that their code is valid before calling mrustc.
This is fine for a project with the goal of providing an alternative bootstrapping path for rustc. The rustc codebase is known to be valid Rust, more or less by definition, since rustc is self-hosting and Rust is defined by rustc’s implementation rather than by a specification.
