I posted a related idea for this same issue as it presents during validation (and presumably deployment as well)
https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/46137910-local-metadata-ignored-if-name-collides-across-an

SFDX CLI default behavior does not retrieve unlocked package components. If I retrieve wildcard on Lightning Web Components, I only get my local Lightning Web Components. Nothing from unlocked packages is retrieved.

Gearset must be doing something additional during comparison to retrieve unlocked package contents in addition to SF's default retrieve behavior. Because Gearset is now changing Salesforce's default retrieve behavior this must be an opt-in feature. Not everyone wants to retrieve the contents of unlocked packages to their repository.

Because this is NOT an opt-in feature, this creates new problems. There is currently a separate, but related, bug in the Gearset comparison behavior. During comparison, components of Namespaced Unlocked Packages are retrieved, and the Namespace is lost or dropped. When a component behind the namespace has the same name as a component outside of the namespace, the comparison combines the two components into a single file or folder. In the case of Lightning Web Components, two colliding components are two folders of various files; and when the bug occurs all the files between the two components are combined into a single LWC folder.

There are identified work arounds using regex and manually maintaining my Comparison Filters. This does not scale and requires too much effort from our team to maintain. Most interestingly, and somewhat frustratingly, the Gearset Comparison Filters' Advanced Settings properly identifies the namespaced unlocked package and lists the components using their namespace. Frustrating because apparently when the Comparison itself is executed that same namespace is forgotten.

Finally, I see this as two separate issues -

1. Gearset should not by default retrieve Namespaced Unlocked Package components. But should be an opt-in feature similar to managed packages.
2. Gearset cannot drop the namespace for Namespaced Unlocked Package components during comparison execution.

Just feels funny that even after 4 years gearset is not trying hard to adopt unlocked packaged.. This is must haves in 2023 and beyond.

This overlap is creating big headaches for our team as we are transitioning from monolithic deployments to DX packages.

I've tested this out by querying the Tooling API's Package2Member Object against specific metadata ID's. If the metadata is in a Package2 package, a single result is returned. If the metadata is not in any package, or even in a managed package, the query returns no results.