Do opaque struct changes break C library ABIs

[Russ Allbery <rra@debian.org>]

I have a C shared library that takes a pointer to an opaque struct as the
first argument to most of its API calls.  The internal layout of that
opaque struct is changing (to add new members).  The only way to create
the opaque state struct is via a call to remctl_new(), which returns a
pointer to it.  Nothing else about the ABI is changing, and client
programs cannot see or manipulate the struct members directly (at least
without poking about in memory, of course).

Is that an ABI break that requires an SONAME change?

If you have two versions of the library loaded in memory at the same time,
call remctl_new() from one version, and then call functions from the other
version, this will break horribly, since the struct layout has changed and
will be misinterpreted.  However, all the ABI calls are identical between
the two versions of the library, so this would require the dynamic linker
resolve two calls to the same library differently.  Also, if both
libraries have the same SONAME, I don't see any way that you could load
two versions into memory at the same time without playing tricks with
dlopen() that I don't see any reason to support.

Is that something that one has to guard against, or can one assume that
the ABI calls from a client of a shared library will be consistent in this
situation: that all the symbols will resolve to the same version of the
shared library when both share the same SONAME?

I'm pretty sure this change is not an ABI break, but the more I thought
about it, the more I wasn't absolutely certain that I had the right mental
model here, so I thought I'd ask.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>