external_lock issues

Description

I've found a couple of interesting things trying to use external_lock in anger.

I'll explain them, then I guess we can discuss if I'm just an idiot (entirely possible), if my expectation is wrong, or if theres a gap in functionality. I'm happy to actually do the work to "fix" if we agree this is a genuine issue.

Goal - I have solution A (lives in 1 repository) and solution B (lives in another repository) and both need to depend on the same version of solution C (which lives in another repository) , which publishes itself as a nuget package.

Repro steps

Issue 1:

No way to specify storage for external_lock files.

For the group Main we have storage : none, but for various reasons we use storage: symlink on some of our nuget packages. There is no way to specify that for an external lock. If in the external lock the storage is set to symlink, that doesn't translate to the "local" lock.

Potential solutions: Respect storage option from external_lock or allow setting (life is done for nuget, etc)

Issue 2:

In order to try to work around issue 1 I moved the external_lock reference to a new group with storage : symlink. The packages from the group are not added to the local lock file as they are if in main group.

Potential solutions: Make external_lock work in groups.

Expected behavior

The ultimate goal of both issues above is to allow an external lock file to set the storage option for the packages listed within it.

Actual behavior

Issue 1: storage option is discarded from external_lock file, no option to override in local dependencies file.
Issue 2: external_lock contents are discarded.

Known workarounds

None at this time.
Put external lock in main group with "storage : symlink" and move everything else into groups . In my case this involved editing ~200 paket.references files, but it seems to work.

Other info:
Paket version 5.249.2. Windows 10. netsdk style projects.

I can probably make up some contrived example and make public is required?

Start by tracing external_lock handling alongside group and storage processing; the issue does not name a source file or test. Check how paket.references and the local lock file represent external-lock contents. Done means external locks preserve or allow overriding storage settings and continue to work when placed in groups.