Whenever we want to use types as markers, it's slightly better to use an uninhabitable enum pub enum KindTypes {} as this makes it impossible to construct the value (by mistake), but can still be used in the generic argument position.

done

Almost all of the types can be easily inferred in the return position; specifying turbofish ::<T> here is, I feel, adding unnecessary visual noise that distract slightly from the actual logic.

The issue is that 'almost all' comment. I prefer a more regular, obvious form that doesn't require the reader to be aware of just when the type can be inferred. WDYT?

but done after f2f

ditto here and in all of the similar places

as above, so below

Instead of relying on strum in our public API, and forcing users to use it, I wonder if it is possible to use the standard std::str::FromStr instead, and keep strum as an internal implementation detail.

It has to be TryFrom because it is a partial function.

FromStr also returns a Result<>:
https://doc.rust-lang.org/std/str/trait.FromStr.html

pub trait FromStr: Sized {
    type Err;

    fn from_str(s: &str) -> Result<Self, Self::Err>;
}

and is also typically used for many other rust types via "value".parse().

For us, we can use #[derive(strum::EnumString)] which auto-derives std::str::FromStr on the enum, but that is an implementation detail.

the problem is that the Err associated type in FromStr needs to implement std::fmt::Debug, but it isn't possible to constrain the associated type using stable Rust.

Either you or @Xanewok may have a solution - the only one I have propagates the constraint on the associated type all through the codebase.

I see. What do you think about simply using String as the error type for FromStr? this also has the advantage of providing an actual error message, instead of the (only) Unit variant strum::ParseError::VariantNotFound. The API will then be idiomatic, without exposing/depending on the highly-specific strum.

Not blocking though if it is not feasible. Just a minor suggestion.

I tried that, but no joy, because the specification of the Err type still causes difficulties. My preference is to use an associated type constraint, as soon as it is stabilised. It is a significant improvement to the type system.

I'll take quick look if we can simplify this.