Unlocked packages vs Unmanaged packages

Unlocked Packages are more like an advanced form of Managed Packages, not Unmanaged Packages. Many of the same differences exist for Unlocked Packages and Managed Packages as compared to Unmanaged Packages.

Upgrade Components

Unlocked Packages can be upgraded, like Managed Packages. Unmanaged Packages cannot be upgraded without uninstalling.

Downgrade Components

Unlocked Packages can be downgraded. Managed Packages and Unmanaged Packages cannot be downgraded.

Dependencies

Unlocked Packages can have dependencies on other packages, both Managed Packages and Unlocked Packages. Managed Packages cannot have dependencies on Unlocked Packages.

Multiple Packages

Unlocked Packages can have multiple packages in a single org, unlike Managed Packages, which each require their own org.

Namespace Differences

Managed Packages support Namespaces. Unlocked Packages may only exist in a Managed Package namespace, or in a null namespace, like Unmanaged Packages.

Delete Components

Unlocked Packages can delete metadata that is obsolete, unlike Managed Packages (with limited exceptions). Unlocked Packages can optionally not delete metadata that is obsolete, unlike Unmanaged Packages.

Source of Truth

Unlocked Packages are always sourced from local files, while Unmanaged Packages and Managed Packages always source from an org.

---

As you can see, Unlocked Packages are more of a hybrid between Managed Packages and Unmanaged Packages, leaning towards the Managed Package end of the feature spectrum. They are far more convenient than Unmanaged Packages for almost all use cases, except the obvious one-off "share the package with the others" scenario, and often more convenient than Managed Packages for non-ISVs (though they also help ISVs).

As for me, the most important difference is that the unlocked package uses SFDX for development. So you, as a developer, could create a package, create a new version, promote, install to org within only SFDX. So it is possible to script all required actions, so that automate the process and use CI in the development of the package.

Unlocked Package

• 2-nd generation package
• requires enabled DevHub and Packaging feature on DevHub on an org
• uses SFDX and all its powerful instruments for development (like sfdx force:source:push sfdx force:source:pull CLI commands)
• source of truth is your version control system
• uses scratch orgs for development
• can have dependencies on other 2-nd gen packages

Unmanaged Package

• first-generation package
• commonly uses Metadata API to develop components of the package
• source of truth is a developer org
• you need to manually add components to a package, upload new version from dev org by means of UI