Greg is a great guy and very knowledgable about storage technology. Unfortunately, there are still a few things that need some correction/clarification.
'NVMe has no concept of controller and LUN; the two concepts are merged in an NVMe "Name Space".' I'm afraid this is simply incorrect. The NVMe Controller is a major part of the NVM Subsystem. It is the NVMe controller that not only creates and maintains the access to the NVMe Namespace (the equivalent of a LUN in NVMe-speak), but is also the structure in a NVMe solution that handles the Queue Pair (QP) relationships.
Not only are NVMe Controllers not equivalent to Namespaces (or combined), it is possible to have "public" namespaces that are accessed by more than one NVMe Controller.
From there, many of the optional features in NVMe (and NVMe-oF) are managed by several controller functions that are indigenous to the relationship between the host and the NVM Subsystem that are independent of the Namespace(s).
"For an array controller, they will layer services behind each NVMe name space (software and hardware)". Given the previous reference to layering services "on top" by way of the storage controller (i.e., not NVMe Controller, but the array controller), this is also incorrect. The architecture for the NVM Subsystem does not place services in between a namespace and the corresponding media, (i.e., "behind the namespace.").
It is true, however, that several companies (both startup and established) have created mechanisms for enhancing services both within and outside of the NVMe controller, but no "array functionality" is inserted between namespaces and media to my knowledge. (Note: this is not to say that someone couldn't create, or possibly doesn't create, a "meta-namespace" in which array functionality could be inserted in between, but this is not a standards-based approach).
"For the array case, for all practical purposes they will advertise multiple Name Spaces, typically one per exported storage area (read this as Controller + LUN). This will be virtualised storage, so each exported storage area will be RAIDed, replicated or erasure-coded." This is mostly true, but with one minor tweak. Storage arrays that do this are likely to treat itself as both the host and the storage target.
That is, the multiple namespaces that it manages will not be presented directly to the hosts. Instead, what happens is that the array controller will often establish individual namespaces with each NVMe drive, which in turn will be aggregated by the array controller (just like you would find with any other disk volume). Then, on the host-facing side, the array will maintain a separate target functionality and present a NVMe target to the corresponding host.
Why is this important? Because the QP relationship between the actual host and the storage media is not contiguous. There are trade-offs - both positive and negative - to doing this, so it's neither a 'good thing' or a 'bad thing.' It's just an architectural implementation choice, that's all. But it is important when comparing to the "distributed file storage" mechanisms that are also discussed here.
With respect to FC-NVMe, "Essentially the effort is to export a virtualised LUN in the form of an NVMe NameSpace, and register this name with the FC switch NameServer; so it can be discovered by FC-NVMe Initiators." This is 100% correct. :)
I would also make a comment about the last paragraph ("Comment+"), but I see there is a clarification here in the comments already. :)