A two-project example showing why identical plug-ins, configuration and packages may be required independently, and how browser warnings differ from Windows protection.
Redundancy depends on purpose, not content alone. When two projects independently load matching configuration or packages, DUPESPACE should require context review or exclude them instead of removing one.
Create Project-A and Project-B with their own package.json files.
Give both projects an identical config/theme.json.
Place the same test plug-in under each node_modules folder.
Add matching installer copies under Downloads as a non-project comparison.
Workspace/Project-A/config/theme.jsonWorkspace/Project-B/config/theme.jsonThe bytes match, but each file belongs to an independent root containing a project manifest.
Next: The browser requires context review; the Windows app must not auto-select either copy.Workspace/Project-A/node_modules/demo-plugin/index.jsWorkspace/Project-B/node_modules/demo-plugin/index.jsSeparate package managers may maintain both files, and removing one can break its project.
Next: Exclude the package environments instead of counting them as reclaimable space.Downloads/setup.exeDownloads/setup (1).exeThe bytes match outside a recognized project root, but the pair is still only a duplicate candidate.
Next: Review the version, signature and offline-install need before using the Recycle Bin.Applications normally load configuration, plug-ins and packages from fixed relative paths. Removing Project-B's copy does not make it use Project-A's file automatically.
Hard links and symbolic links are separate relationships and do not belong in ordinary duplicate cleanup. The Windows app avoids those special objects and does not traverse junctions or reparse points.
Current rules look for .git, .svn, package manifests and lockfiles, pyproject.toml, requirements files, node_modules, virtual environments and common application files. The browser marks context for review; Windows excludes or locks recognized project and package locations.
This is a conservative boundary, not a dependency analyzer. Custom build systems, portable apps and internal directory layouts may have no known marker, so explicit protected subfolders remain necessary.
To reduce a project's size, use its package manager, build tool or documented cleanup command to remove reproducible outputs. Do not delete individual dependencies by comparing them with another project.
Review ordinary duplicate candidates only in clearly understood personal folders and only after excluding application, backup, sync and work contexts.
Windows handles recognized project roots conservatively, while the browser marks them for review. Add custom structures to protection explicitly.
Do not remove them file by file. Use the package manager or rebuild the environment so dependencies and lockfiles remain consistent.
They do when separate applications read from their own paths. Only someone who understands the loading behavior can safely redesign them as shared state.