Specifying dev-dependencies through Cargo feature flags - rust

Question

The Background
I am working on a Rust crate. It has several [dependencies] and several [dev-dependencies]. Some dev-dependencies are new crates, but some are just enabling features of crates that are already specified as dependencies.
For example, I use serde in my crate, but don't need to derive any serialization impls. However, for my tests I do need to derive them, so my Cargo.toml file looked like this:
[package]
name = "example"
version = "73015087.0.0"
edition = "2021"
[lib]
path = "/dev/null"
[dependencies]
serde = "1.0.139"
[dev-dependencies]
serde = { version = "1.0.139", features = ["derive"] }
I didn't like needing to duplicate the version number where I (or tools) might forget to update it in sync with the other one, so I changed the dev-dependency to use an unbounded version:
[dev-dependencies]
serde = { version = ">=0", features = ["derive"] }
This felt kind-of gross (particularly since we need to work around crates.io forbidding truly unbounded versions with *). I don't want to be specifying a second dependency on serde, I just want to enable a feature. I ended up with the following alternative.
The Idea
Instead of specifying my dev-dependencies directly under [dev-dependencies], I specified a dependency back on the crate itself, but with a feature flag named dev-dependencies enabled. I used the this flag to enable serde's derive feature without needing to duplicate the version number or use an unbounded range:
[package]
name = "example"
version = "73015087.0.0"
edition = "2021"
[lib]
path = "/dev/null"
[dependencies]
serde = "1.0.139"
[dev-dependencies]
example = { path = ".", default-features = false, features = ["dev-dependencies"] }
[features]
dev-dependencies = [
"serde/derive",
]
After playing with this, I realized that I could use this to list all the versions of all types of dependencies under [dependencies], by adding them as optional and enabling them through the new flag. For example, here is how I've added expect-test, instead of putting it under dev-dependencies.
[package]
name = "example"
version = "73015087.0.0"
edition = "2021"
[lib]
path = "/dev/null"
[dependencies]
expect-test = { version = "1.3.0", optional = true }
serde = "1.0.139"
[dev-dependencies]
example = { path = ".", default-features = false, features = ["dev-dependencies"] }
[features]
dev-dependencies = [
"serde/derive",
"expect-test",
]
It's a little weird, but I might prefer to have all of the versions in one place and avoid the potential duplication. I'm deciding whether to stick with it.
The Question
Does this produce any significant differences in behaviour from expressing dev-dependencies the conventional way, or is it equivalent? Am I going to end up with more confusing resolver issues down the line?
Here are the resolutions with and without dev dependencies enabled, according to cargo-tree:
$ cargo tree -e normal
example v73015087.0.0 (/workspaces/example)
└── serde v1.0.139
$ cargo tree -e normal,dev
example v73015087.0.0 (/workspaces/example)
├── expect-test v1.3.0
│ ├── dissimilar v1.0.4
│ └── once_cell v1.13.0
└── serde v1.0.139
└── serde_derive v1.0.139 (proc-macro)
├── proc-macro2 v1.0.40
│ └── unicode-ident v1.0.2
├── quote v1.0.20
│ └── proc-macro2 v1.0.40 (*)
└── syn v1.0.98
├── proc-macro2 v1.0.40 (*)
├── quote v1.0.20 (*)
└── unicode-ident v1.0.2
[dev-dependencies]
└── example v73015087.0.0 (/workspaces/example) (*)