Being able to change things. It's like all downsides of backwards compatibility but on a binary level

As to things ABI prevents:

- scoped_lock was added to not break ABI by modifying lock_guard

- int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated.

- unique_ptr could fit in register with language modifications, which would be needed to make it zero-overhead, compared to a pointer

- Many changes to error_code were rejected because they would break ABI

- status_code raised ABI concerns

- A proposal to add a filter to recursive_directory_iterator was rejected because it was an ABI break

- A proposal to make most of <cstring> constexpr (including strlen) will probably die because it would be an ABI break.

- Adding UTF-8 support to regex is an ABI break

- Adding support for realloc or returning the allocated size is an ABI break for polymorphic allocators

- Making destructors implicitly virtual in polymorphic classes

- Return type of push_back could be improved with an ABI break

- Improving shared_ptr would be an ABI break

- [[no_unique_address]] could be inferred by the compiler should we not care at all about ABI

Source: https://cor3ntin.github.io/posts/abi/

> Making destructors implicitly virtual in polymorphic classes

Not sure what to think of this one. Either one introduces a new keyword to opt out (not great), or all public destructors of an abstract base class are implicitly marked virtual (not great and another "hidden" language feature like threadsafe-statics).

After all, an abstract base class does not need its destructor to be public.