nit: the build process is the same either way right?cargo build --target <uefi-target>

The three sections above are essentially all "what isuefi +std" -- I think it would be clearer to shorten down to a quick explanation that there is ongoing work to add more support forstd to the UEFI targets in rust with link(s) to where more info can be found, then show the example.

Yeah, I also wasn't that happy with them. Do you like the new version better?

I think we should avoid making claims about it being recommended or not -- we can stick to just the facts and note that uefi+std is still in progress and gated by an unstable flag.

I hope the new phrasing is better?

result -> the compiled result

I'm still not 100% satisfied with the phrasing of this paragraph. Any idea?

One thing that would help I think is to drop the "standard binary" terminology; stick tono_std and thestd crate.

Here's my attempt:

Programs created with theuefi crate are typically created withno_std andno_main. Ano_std crate can use thecore andalloc parts of Rust's standard library, but notstd. Ano_main executable does not use the standardmain entry point, and must define its own entry point;uefi provides theentry macro for this purpose.

Rust has added partial support for building UEFI executables withoutno_std andno_main. Some functionality requires a nightly toolchain, and some parts ofstd are gated by the unstableuefi_std feature. Follow thetracking issue for details.