Packages provide a namespace for packagableElements.
As a namespace, visibility is specified using the makesVisible method. Only private and public visibility is used, if not set it's public. In addition to the ownedMember also the imported members can be made visible.
The namespace also implies ownership (owningPackage subsets namespace subsets owner).
Because Package is also a packagableElement, Packages can be nested. This leads to the special association nestingPackage-nestedPackage which subsets the association owningPackage-packagedElement. Also namespaces could be nested, they didn't receive this special association.
The same subsetting mechanism is used for the Type metaclass: package-ownedType. Type serves as super-class for classifiers, which are further specialized to classes and interfaces.
The classes that directly inherit from PackagableElement and not from Type are ValueSpecification and Constraint.
Both subsetting associations are marked as derived, so an implementation would need to search the list of packagedElements for all that conform the 'Type' respective 'Package'.
The package also overwrites mustBeOwned with false.
There is also a class PackageMerge which describes how to resolve the conflicts when two packages are merged. This is used a lot in the infrastructure itself, but I wonder if it's useful when working with real code (especially LabVIEW with it's difficulties of merging single VIs). Also it is a very long paragraph, so I ignore it.