I.22 Various issues

Firstly, the explanation in I.22 says that one of the initializations access an uninitialized object. I believe that this is not correct, and instead, a zero-initialized object is accessed.

It's somewhat unclear whether "complex initialization" is supposed to mean dynamic initialization, though I would assume that it is intended to.

Dynamic initialization is not a problem in principle, and it can be quite beneficial. For example:

inline const std::array<double, 128> sin_table = [] {
    decltype(sin_table) result;
    for (std::size_t = 0; i < sin_table.size(); ++i) {
        result[i] = std::sin(std::numbers::pi * 2 * i / sin_table.size());
    }
    return sin_table;
}();

Until C++26, sin_table could not be constexpr, yet it's entirely reasonable and even best practice to use dynamic initialization, since the only alternative is hand-writing the initializer-list, or writing your own constexpr sin function¹⁾. Neither of these are very practical.

¹⁾This would be a solution because only non-constexpr functions are meant to be flagged by the current Enforcement standards

Suggested Solution

(Easy) use zero-initialization and dynamic initialization correctly in the current wording, and add an exception for dynamic initialization that only accesses objects within the current TU, or functions which act as a "pseudo-constructor", such as the lambda above.

(Hard) additionally reword the rule in terms of Avoid dynamic initialization which relies on objects in other translation units

Start by reading the I.22 rule linked in the issue and reviewing the distinction between zero-initialization and dynamic initialization. Compare the current wording with the suggested exception and broader rewording; done means the guideline accurately describes the initialization hazard and clearly defines any permitted cases.