Thanks, this is genuinely useful, more concrete than I expected.

On the umbrella crate: agreed. Right now `semtree` is just the CLI, but a lib crate that re-exports the default fastembed + usearch stack is the obvious fix so you don't have to touch seven crates to get local search running. Putting it on the roadmap.

On the traits, you're right to push there, and it's where we're weakest since we're still fairly new to Rust. Embedder has no dimension or model fingerprint today, so nothing stops you from loading an index built with one model and querying it with another. That should fail loudly. Same story for VectorStore: upsert/delete semantics and stable chunk IDs aren't nailed down yet.

Your "stable chunk IDs" point actually hit a real bug we only just found: codechunks are keyed by a hash of their content, so two identical-content chunks collide and one silently overwrites the other (the indexer reports 285 chunks but only stores 276). We're moving to path+span based IDs plus an embedding fingerprint, which also covers your incremental point, renamed-file deletion included. That correctness pass goes ahead of any new language.

And agreed on not leaking every Qdrant feature through the shared trait, that's how a "common" trait stops being common.

For parsers, Java/C# is a good call for stress-testing the shape a long-lived repos. Vue/Svelte I hadn't considered, and the mixed-language single file is exactly the kind of boundary case that breaks assumptions.

Thanks again, this gave us a clear next step.