So I interpreted this implies f1_out here is the redefined flow's f1_out if the flow redefines a flow. Is that the correct? That means in the example above, in Flow f21, the redefined output must be f1's output instead of a11's output. Actually, I did not know that is the rule.

That is not really what it says in what you quoted from the specification. What the spec says is that the FlowEnd has an owned Feature redefining f1_out. It doesn't say actually anything about what happens if the flow itself redefines another flow. However, a redefinition of these nested features kind of happens anyway due to the implied redefinitions of sourceOutput and targetInput.

In your example, the redefined flow f1 is parsed like (with implied specializations added):

flow f1 subsets Flows::flows {
    // First FlowEnd
    end references a11 redefines Flows::flows::source {
        out redefines a11::output, Transfers::Transfer::source::sourceOutput;
    }
    // Second FlowEnd
    end references a12 redefines Flows::flows::target {
        in redefines  a12::input, Transfers::Transfer::target::targetInput;
    }
}

The redefining flow is then parsed like:

flow f2 redefines a1::f1 {
    // First FlowEnd
    end references a11 redefines a1::f1::source {
        out redefines a11::output, Transfers::Transfer::source::sourceOutput;
    }
    // Second FlowEnd
    end references a12 redefines a1::f1::target {
        in redefines  a12::input, Transfers::Transfer::target::targetInput;
    }
}

Because of the checkFeatureEndRedefinition constraint, the ends of f2 redefine the ends of f1. The features nested in the two ends (output and input, respectively) don't explicitly redefine the corresponding nested features from the ends of f1. However, the corresponding nested features both redefine the same ancestor feature (sourceOutput or targetInput). As a result, by the semantics of redefinition, the nested feature f2::source::output effectively redefines f1::source::output (and, in fact, f1::source::output is therefore not inherited), and similarly for f1::target::input.

This was a particularly subtle aspect of redefinition that we had to carefully work out when we formalized the computation of inherited memberships!