I’d like to know if we still should use
buildInputsandnativeBuildInputs
Yes you should. The reasoning behind labeling them ‘legacy’ is because mkDerivation was overhauled to support the full host/build/target relation some time in the past.
In the new model depsBuildHost or depsBuildHost would be more accurate descriptions of these variables, but as the manual details the old names are retained for historical continuity.
I guess legacy implies there’s something newer you should use instead, but that’s not the case. It’s just about the naming scheme. That’s somewhat unfortunate…
Also, what is the difference between native and non-native within the build script?
This distinction is of importance when cross compiling. I scrapped my own explanation of these terms, and will just cite the relevant bits of the manual instead:
nativeBuildInputsThese are programs and libraries used at build-time that, if they are a compiler or similar tool, produce code to run at run-time—i.e. tools used to build the new derivation.
buildInputsThese are often programs and libraries used by the new derivation at run-time, but that isn’t always the case. For example, the machine code in a statically-linked library is only used at run-time, but the derivation containing the library is only needed at build-time.
My mental heuristic that gets it right most of the time (I guess) is: if it’s run or otherwise used at build time it’s a nativeBuildInput, otherwise buildInput.
Even if you’re not cross compiling yourself, try to get them right - someone might try to cross compile your derivation one day.
All of this is answered in the nixpkgs manual in much more detail.