Compare managed, unmanaged and unlocked packages, and give a scenario for each.

Managed — built in an org with a registered namespace, source protected, upgradeable by the publisher, and subject to restrictions on what can be changed or removed once released. Scenario: an ISV distributing through AppExchange that needs IP protection and a supported upgrade path to installed customers.

Unlocked — versioned and upgradeable, developed from source control, but the metadata remains visible and editable in the installed org. Scenario: an enterprise modularising its own org so teams own separate functional areas with independent version history, or sharing a common integration framework across several of its own production orgs.

Unmanaged — a one-time copy; components land as ordinary editable metadata with no namespace isolation and no upgrade path. Scenario: a consultancy handing a client a starter template the client will own outright and the consultancy will not maintain.

The mistake I watch for is choosing managed for an internal modularisation exercise. It locks the customer out of its own configuration and imposes ISV-shaped constraints for benefits — IP protection, publisher-controlled upgrades — that an internal team does not need.