It will be completely standalone. The same way it works with Rust, Go, etc. The binary size will be smaller than Go but bigger than Rust.
Portability is by definition not possible with natively compiled binaries however. It is a choice - either produce an assembly (still single-file, .NET can do this unlike JVM offerings) that is completely portable, or produce a self-contained executable targeted at a particular OS and ISA.
Sure, but not cross-platform, which the previous comment seemed to indicate that GraalVM could, which it cannot. Both tools need to compile on the platform they target, compared to Go/Rust where you can target other platforms even though you're not compiling on them.
Cross compilation is a toolchain feature, not a programming language capability.
As for GraalVM, it has plenty of modes, the AOT one that is being talked about here, is native image.
Which can also use a JAR file as input, so even though it doesn't yet support cross-compilation, you can use the JAR file as single source, and then have a couple of build environments in e.g. Github pipelines.
To the end user it doesn't matter as long as they get their shinny executable available, and it only has to be done once as a project template.
Also note that cross-compiling only really works without issues for whatever compiled language, if the toolchains have access to every single library from the target system on the host environment, and no dependencies FFI into other languages.
I was talking about .NET's publish modes (NativeAOT, portable assembly, etc.).
You are also confusing what it means to produce a portable assembly with the ability to target across operating systems or CPU architectures.
(also, most native toolchains do not let you easily cross-compile, Go makes significant sacrifices to make it possible, as long as you have no dependencies which rely on C/C++, and there are many of those)
