Partial update with -w/-W reports a symlinked path-repository package's locked dependency as "not loaded, likely because it conflicts with another require"

composer update -w <pkg> fails when the project contains a path-repository package whose own dependency is locked but not in the update allow list. Composer reports that dependency as "not loaded, likely because it conflicts with another require" even though the locked version satisfies the constraint and appears in the "found" list. The identical project without the path package resolves the same command cleanly.

Composer 2.10.2, PHP 8.5.9 (macOS), also reproduced on PHP 8.4 in a Linux container. COMPOSER_POOL_OPTIMIZER=0 makes no difference, and neither does policy.advisories.block: false, so this is not the pool optimizer and not advisory blocking.

Reproduction

liby/composer.json (the path package; no git metadata needed):

{
    "name": "acme/liby",
    "version": "1.0.0",
    "require": { "symfony/process": "^7.0" }
}

proj/composer.json:

{
    "repositories": [ { "type": "path", "url": "../liby", "options": {"symlink": true} } ],
    "require": {
        "acme/liby": "*",
        "league/flysystem-aws-s3-v3": "^2.0",
        "aws/aws-sdk-php": "3.384.8",
        "mtdowling/jmespath.php": "2.8.0"
    },
    "config": {"policy": {"advisories": {"block": false}}}
}

The two exact requires exist only to build an outdated lock, and the advisories config only because jmespath 2.8.0 has picked up an advisory since; the point is a lock file that holds aws 3.384.8 + jmespath 2.8.0, which real projects locked before the advisory have.

cd proj
composer update

Now delete the aws/aws-sdk-php and mtdowling/jmespath.php requires and the config block from proj/composer.json (leaving acme/liby and league/flysystem-aws-s3-v3), and run:

composer update --dry-run -w aws/aws-sdk-php

Actual:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires acme/liby * -> satisfiable by acme/liby[1.0.0].
    - acme/liby 1.0.0 requires symfony/process ^7.0 -> found symfony/process[v7.0.0, ..., v7.4.13] but these were not loaded, likely because it conflicts with another require.

Expected: the same result as the identical project without acme/liby, which is

  - Upgrading aws/aws-sdk-php (3.384.8 => 3.391.0)
  - Upgrading mtdowling/jmespath.php (2.8.0 => 2.9.2)

What I've ruled out and narrowed down

• symfony/process is locked at v7.4.13, which satisfies acme/liby's ^7.0, and v7.4.13 is in the "found" list of the error. So even the locked version never made it into the pool.
• -W fails the same way as -w.
• Plain composer update aws/aws-sdk-php (no -w) resolves in the same project. It comes back with "Nothing to modify in lock file", since the jmespath 2.8.0 pin blocks every newer aws release — that silent no-op is why -w is wanted here in the first place.
• The path package doesn't need to be a git checkout: a plain directory with a version field reproduces, as does a git checkout on any branch. A dev-main constraint instead of * changes nothing.
• The failure is specific to a symlinked (or auto-symlinked) path package. Setting options.symlink to false and refreshing that package's lock metadata makes the partial update succeed.
• Single-package partial updates elsewhere in the tree all succeed (composer update mtdowling/jmespath.php, composer update symfony/filesystem). Explicitly listing the pinned dependency succeeds: composer update aws/aws-sdk-php mtdowling/jmespath.php. Adding either symfony/process or the path package itself to the -w list also succeeds.

I hit this through a CMS package-manager UI that wraps composer and runs -w for targeted updates, in a dev environment that consumes two libraries via symlinked path repositories.

Happy to test a patch or narrow it down further.