This is different from previous posts about this issue because this time I can't make out any pinned versioning of the conflicted crate. Running cargo update -p proc-macro2 updated the crate proc-macro2 v1.0.39 -> v1.0.47 and then the build started working again.
error: failed to select a version for `proc-macro2`.
... required by package `clap_derive v4.0.21`
... which satisfies dependency `clap_derive = "=4.0.21"` of package `clap v4.0.26`
... which satisfies dependency `clap = "^4.0"` (locked to 4.0.26) of package `mycrate`
... which satisfies path dependency `mycrate` of package `mypackage`
versions that meet the requirements `^1.0.42` are: 1.0.47, 1.0.46, 1.0.45, 1.0.44, 1.0.43, 1.0.42
all possible versions conflict with previously selected packages.
previously selected package `proc-macro2 v1.0.39`
... which satisfies dependency `proc-macro2 = "^1"` (locked to 1.0.39) of package `actix-web-codegen v4.0.1`
... which satisfies dependency `actix-web-codegen = "^4"` (locked to 4.0.1) of package `actix-web v4.1.0`
... which satisfies dependency `actix-web = "^4"` (locked to 4.1.0) of package `actix-files v0.6.1`
... which satisfies dependency `actix-files = "^0.6.1"` (locked to 0.6.1) of package `anothercrate`
... which satisfies path dependency `anothercrate` (locked to 0.0.0) of package `mypackage`
failed to select a version for `proc-macro2` which could resolve this conflict
Can't Cargo could automatically update packages in this scenario to make them satisfy constraints?
The carat (^0.0.0) syntax does allow the crate to be updated till ^0.0.z in the scenario that patch version is specified, which seems to be the case here.