As the author of Ncat, I disagree that it has "very different output" from traditional and OpenBSD netcats. Unless you specify -v (verbose mode), Ncat usually doesn't have any output at all. It silently connects to a remote system (or listens for connections from remote systems) and relays exactly what those systems transmit. Also, nc.traditional does not even support IPv6. A failure because the remote host only supports IPv6 seems a lot more problematic than any alleged difference in output. The traditional nc doesn't support SSL encryption either. That's a problem for communicating with modern web sites and mail servers as well as for communicating securely between ncat instances. Also Ncat fully supports Windows and Mac, so users can interoperate between more systems. And it's more performance in many cases since it supports modern Linux I/O API's rather than just select and poll. Also traditional netcat is not maintained by any particular organization.
For these reasons, we support having Ncat be one of the official Debian Netcat alternatives. It's already the default on many other distributions, including Red Hat Enterprise Linux, Fedora, etc. We also love traditional and OpenBSD netcats and are glad those are offered by Debian and Kali as well. Cheers, Gordon "Fyodor" Lyon