It feels like the natural direction of this argument is that matplotlib should just not ship built-in styles named after other IP, versioned or not.

@mwaskom I agree that avoiding naming styles after other IP would've been the best choice originally (especially if you and other authors of those styles weren't consulted), though given that it's already happened, I think the decision is less obvious. Apologies if this was already discussed, but perhaps another (imperfect) option would be to append like to the names: seabornlike, ggplotlike, etc. This would still cause some technical debt to existing users of these styles, but at least it would avoid the need to remember styles with names like seaborn_v0_8-whitegrid and fivethirtyeight_v2022-Oct-23_10_27_43 :)

I don't think you really need to worry about that because the "fivethirtyeight" (and "ggplot") styles are closer to an emulation or homage than an attempt at direct replications. (The ggplot style is pretty far off what what default ggplot looks like; I'm less familiar with fivethirtyeight but I think their plots are typically more stylized than you could achieve just through rcParams).

Whereas seaborn defines its styles in terms of matplotlib rcParams so matplotlib could, in theory, achieve exactly the same results (and it is confusing when it doesn't).

Also, I believe that matplotlib plans to deprecate the seaborn style and to keep the versioned name only for backwards compatibility, not to introduce the concept of "versioned styles" on an ongoing basis.

not to introduce the concept of "versioned styles" on an ongoing basis.

Eh, we've discussed this, in part as a way to more easily facilitate deprecation of styles and as a path for creating new styles that could then be more easily updated. The discussion kinda started at #23598 (comment)

I think the discussion in that issue comment is a little bit different — I take that as adopting an internal versioning system for matplotlib themes, not instituting a rule that themes based on external libraries will track those libraries versions.

I it unlikely we are going to change course on the 'seaborn' style. We can not both a) keep our styles consistent over time (because the visual output if Matpoltlib is part of our API) b) track changes in actual seaborn's styling. Given that tension we decided to remove the name, but keep seaborn-v0_8* around to give a back-compatibility path if needed and to be clear that it is the style that matches seaborn v0.8.

@mwaskom is correct, the discussion going about how to do "versioned styles" about being able to update home-grown styles (like "dark") rather than to accommodate following external IP.

FWIW the seaborn situation is kind of a weird edge case because the main reason its style definitions changed was to track matplotlib's changes (in v2.0). But that ship has sailed.

I'm going to close as won't-fix; @cliffckerr, sorry this is a hassle, but this was pretty thoroughly discussed by the dev team when the decision was made so I don't think there is much chance we will directly revert this.

Note that we will soon likely have a way to use styles from installed, but not necessarily imported packages. Perhaps seaborn will make a style file available that tracks their internal styles.

Thanks @jklymak -- I understand there are a lot of competing priorities here and there's no way to satisfy everyone!