Different indentation with single-bound and multi-bounds

Input

fn f1() -> Box<
    FnMut1() -> Thing1<
        WithType = LongItemName,
        Error = LONGLONGLONGLONGLONGONGEvenLongerErrorNameLongerLonger,
    >,
> {
}
fn f2() -> Box<
    FnMu2t() -> Thing2<
            WithType = LongItemName,
            Error = LONGLONGLONGLONGLONGONGEvenLongerErrorNameLongerLonger,
        > + fmt::Write,
> {
}

Output
Same as input.

Expected output
In the above example, Thing1 and Thing2 internal indentation is different because of the addition of the second bound fmt::Write to FnMu2t().

It is not clear which of these indentations is the required indentation, as the guidelines for different cases are not clear. For example, the following where formatted code has the same issue:

fn foo<F>(foo2: F)
where
    F: Fn1(
        // this comment is deleted
    )
{
}
fn foo<F>(foo2: F)
where
    F: Fn2(
            // this comment is deleted
        ) + fmt::Write
{
}

On the other hand, the following formatted impl example is different:

fn build_sorted_static_get_entry_names(
    mut entries: entry,
) -> (
    impl Fn(
        AlphabeticalTraversal,
        Seconddddddddddddddddddddddddddddddddddd,
    ) -> Parammmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
    + Sendddddddddddddddddddddddddddddddddddddddddddd
) {
}

Note that in the where example with a second bound, the closing parenthesis ) is not indented the same as the F of F: Fn2, while in the impl example the ) is under the impl of impl Fn. Although these are different cases, it seems that the formatting guidelines are different.

Is it o.k. that the indentation is changed when a second bound is added? If not, what is the expected output in the above examples?

Meta

• rustfmt version: rustfmt 2.0.0-rc.2-nightly (32e3ee90 2021-03-01)
• From where did you install rustfmt?: self build

Reproduce the reported single-bound, multi-bound, where-clause, and impl examples with the stated rustfmt 2.0.0-rc.2-nightly version. Compare the current output with the expected indentation and determine whether the project has an established rule for these cases; done means the intended behavior is clarified and the relevant formatting behavior is made consistent or documented.