Suppose the following class:

class Obj {
public:
    Obj() = default;
    int calculate(int param)
    {
        // Some calculation that utilizes the scratch buffer
    }

private:
    int x{};
    int y{};
    std::byte scratch_buffer[2048]; // [[indeterminate]] intended
};

Currently, Obj::scratch_buffer will contain indeterminate values.

Maybe. If an object of type Obj has static storage duration, scratch_buffer will initially contain zeroes. If it has dynamic storage duration, scratch_buffer will initially contain indeterminate values, and you can't change that. In C++23 and earlier, if the object of type Obj has automatic storage duration, scratch_buffer initially contains indeterminate values. In the current C++ draft, for automatic storage duration, it's the presence or absence of [[indeterminate]] on that Obj-type definition which says whether scratch_buffer has indeterminate or erroneous values.

 

In C++26, will there be a way for it to opt out of the erroneous value
initialization, sans requiring the user to change the client-side
code?

Unlikely, but note "erroneous behavior" resulting from use of an erroneous value is in a sense "better" than the "undefined behavior" resulting from use of an indeterminate value. An erroneous value is unpredictable but at least behaves as one specific and consistent value, whereas use of an indeterminate value could cause any results for the whole program. As far as I know, this better describes the actual situation in modern architectures (without a "trap representation") with compilers configured to produce efficient executable code (maybe not with a tool or compiler mode for strong linting).