Motivation for associated error type?

[SimonSapin]

I’m working on an other alternative to std::fmt (this time with arbitrary bytes output rather than Unicode, https://foss.heptapod.net/octobus/rust/format-bytes/) and considering having an associated type for errors v.s. a single error type. ufmt presents this as a feature:

A generic Formatter<'_, impl uWrite> instead of a single core::Formatter; the uWrite trait has an associated error type so each writer can choose its error type. For example, the implementation for std::String uses Infallible as its error type.

While the String case is neat, it doesn’t feel very valuable. I can live with an .unwrap() call in a few places with a comment "never panics because String::write_str never errors".

Are there other cases where using a different error type is useful?

[SimonSapin]

A downside that I find more serious is that uDisplay cannot be object-safe, because of its generic method.