Currently the only way I see to register a namespace is to create a developer edition org via the environment hub.
You don't need to use the Environment Hub, any Developer Edition with a Registered Namespace will suffice. Given the new role of namespace orgs, there's no need to have a huge Partner Edition-sized Developer Org, a normal Developer org will suffice. Keep in mind that you can register the same namespace with multiple Dev Hub orgs as well, but you'll have to share passwords or something to make that happen.
Easy enough, but then how would you create multiple packages under that namespace?
Set the namespace property in sfdx-project.json to the desired namespace. All packages created in the project will use this namespace. There's nothing special about this process other than minimal setup.
If one has the developer edition org with namespace and the namespace is registered, how do you create the package using second generation packaging.
You use sfdx force:package:create command, just as you would with Unlocked Packages. The difference is that your Dev Hub would be linked to the namespace, and the namespace would be specified in sfdx-project.json; you should also specify -t Managed to make the package a 2GMP.
When using the packaging command you can generate a package with the namespace but then where does it live? I highly doubt the code will automagically be populated in the namespace org.
The "packaging org" concept only applies to 1GMP. In the new model, the code is stored in package metadata directly in the Dev Hub org, and is not directly exposed in the UI.
This is because your source code repository is now the source of truth, so the metadata doesn't need to "live" in an org in the same sense as a 1GMP requires. No automagical installation/updating of the namespace org is required.
This is also coincidentally the reason why you now only need two orgs (a Dev Hub and a Namespace Org) for any number of packages, instead of one org per package, each with separate namespaces. This can also reduce the number of namespaces you need to keep track of, as all your packages can now share the same namespace.
Given that there is no UI for second generation packaging, how would one support the package in subscriber orgs? Do you still get LMA records created for installations of managed second generation packages if there is no code in the namespace org?
Yes, LMA allows you to log in to Subscriber Orgs with both 1GMP and 2GMP packages. Remember, even in 1GMP, the source code in the org isn't literally the code that's in a subscriber's org. In the 1GMP model, metadata is uploaded to a PackageVersion object, and that's the metadata that's used. In truth, the only real change here is that the metadata is now stored in an org different than the namespace org.
It doesn't matter if you have code in your namespace org, as that has no bearing on the metadata in the subscriber's org. This is also technically true for 1GMP, except that the metadata has to be in the Packaging Org to be uploaded, while in 2GMP, the files are directly uploaded from your computer.
Is the developer org holding the namespace only there to provide the namespace?
Yes. That is the new, sole purpose a Developer Edition org in this context. Development should be done in Scratch Orgs, and packages are uploaded to the Dev Hub org, so DE orgs serve no other purpose at this point, if you're using 2GMP.
Does any code ever make it to the namespace org?
No code will be placed in the namespace org, unless you want to, and is completely unnecessary. The metadata package is now stored in the Dev Hub org instead, but not "installed" in to the Dev Hub. In other words, the Dev Hub holds the metadata used for installation, but doesn't operate with that metadata actually installed in the org.
Is second gen packaging not read for prime time with managed packages in this scenario and we should stick with 1st generation packaging.
In 2018, when this question was asked, it was highly experimental and not well-suited for some types of ISV apps. In this revised 2021 answer, 2GMP is largely ready for prime time.
It's still not really possible to convert a 1GMP to 2GMP (unless you're in the Pilot program), but this should be available at some point in the future.
If you already have a 1GMP, stick with it unless you can convince your subscribers to move to 2GMP, which requires uninstalling the old package and installing the new one. If you're making a new package, use 2GMP now to avoid some hassle.
This answer was heavily modified from the original answer, which is in the revision history for this answer. It has been removed entirely from the main answer body, as it contained a number of factual errors. Thanks to Felix van Hove for bringing this to my attention.
