ISTM the author made an unnecessarily restrictive choice: > A downside is that traits make each choice in an open universe a type, not a value, so operations l

ISTM the author made an unnecessarily restrictive choice: > A downside is that traits make each choice in an open universe a type, not a value, so operations like equality become harder to define. It isn’t impossible, though: the trait could require a key method which returns a many-strings type. #[derive(Eq, PartialEq)] struct ArchitectureKey(pub Cow<'static, str>); pub trait Architecture { // ... fn key(&self) -> ArchitectureKey; } So an architecture is a type that is expected to only have a single value, and a dynamic architecture (from, say, a description in a file) can’t be done in a dignified manner. But ISTM this can be generalized very easily: pub trait Architecture { // ... fn key(&’a self) -> ArchitectureKey<‘a>; } Now an architecture is a value of a type that implements Architecture, and those types can be single- or multiple-valued. And single-valued architectures can be implemented without needing to awkwardly allocate and maybe even leak memory. (The cow::Borrowed in the OP could be used to avoid leaking at the cost of potentially large amounts of useless allocation.). But this variant doesn’t use 'static and avoids this issue.