I don't think #1121 is the right approach. The fallibility here is with (a) parsing the format string, which might be invalid, and (b) whether the type we're formatting from contains enough information to fill out the fields the format string has.

Making something work on 0.4.x is "trivial" in a sense because we can just invent new API that does whatever we want. Postponing the failures of parsing from the parsing stage to the formatting stage doesn't sound like a great option, in particular a reasonable approach is to use a long-lived formatter (parsed from a string) for many values. For getting enough data out of the input type, that seems like something we could assert at compile time using generics.

As such, I think the high-level structure here should be:

1. A fallible function/method that converts a format string to Vec of items (reusing the existing item type if we can)
2. A fallible function/method that binds a Vec or slice (for the non-alloc case) to a particular input type, failing if the type does not contain enough data for the input type
3. The outcome of step 2 would be something like a struct Widget<'a, I> { items: Cow<'a, [Items]>, input: PhantomData<I> } (replacing the Cow with just a slice if alloc is not enabled, I think?) which implements Display and will only fail (as you explained in Make StrftimeItems::new return Result #902 (comment)) if the inner Formatter fails
4. Probably some high level API that wraps over step 2 and 3 above, particularly for the allocating case

To the extent that we can't implement this (efficiently) within the current API (from what I've seen, this will just get ugly with the approach chosen in #902), we should invent a new entry point. The new entry point should be able to satisfy all the use cases for the existing entry points so that we can, at some point in the near future, start deprecating the existing entry points. In particular, there should be affordances for the non-alloc use case and there should be a clean way (that is, with minimal code duplication) to factor in the localization stuff.

cc @jaggededgejustice @pitdicker