Tags and keywords
As it applies to the diagram above (and in comparison with the previous slide), the symbols for the parts demonstrating redefinitions have not been placed inside the symbol for the Usages package. For this sample it probably makes little difference, since as an official SysMLv2 sample it is unlikely to change, but on a real project if you had those parts inside the symbol for the Usages package the View would break if you moved the parts between packages.
For the sake of being able to show the import, the Usages package is included here (and with members listed), but the ownership of the parts is shown just using owning membership relationship symbols. If the parts are moved between packages those membership relationship symbols will simply vanish, which is not ideal, but it doesn't actually break anything.
If you are making a View of a stable target such as a readonly model library, by all means use package symbols and even nested package symbols if it helps.
Otherwise, keep things loose and relational! Stay in your modelling zone focussing on the relationships between elements that have meaning as engineering idioms (similar applies even if you are using a more compartment oriented approach).
Then, take a break from your modelling every now and then to do some ownership housekeeping, supported by high level package overviews that just list members and emphasise dependencies between packages using import relationship symbols. Such diagrams are authored with a different mindset.
Visit also the link above for a discussion of how you can also use user defined Metadata keywords to indicate systems engineering layers rather than relying too heavily on packaging.