This would make it much easier to use Gearset for orgs that have lots of unlocked packages (i.e. pretty much everything from UnofficialSF)

As it is now, the Unofficial SF components show up as differences in the comparison. This makes it much harder to find the real changes.

we have installed a lot of unlocked packages like https://unofficialsf.com/

Now the gearset thinks to delete them :( This is not ideal.. gearset should ignore unlocked packages

This should be available today. The lack of support for unlocked packages in Gearset is a serious consideration when deciding whether our team can take on new dependencies. I would like to add the helpful unofficial sf Flow Components utils for example, but it's just not worth the pain of maintaining the exclusions in the comparison filter.

As an example Unofficial SF's List Functions for Flow, which itself has two other dependencies as well.

https://unofficialsf.com/list-actions-for-flow/#installation

Encountering this very issue now. Surprised to see a suggestion from 2018 that has gone unaddressed. Equally surprised that it hasn't received more than 13 votes!

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.