To me a merger seems difficult. I fear that C would loose its identity and essentially cease to exist. C is is maintained by a separate working group, has different use cases, and serves a different group of users. I can not see that this can work if it also is required to be a subset of C++.
A merger would obviously be difficult. There are differences in overlapping - but incompatible - feature sets and in the text of the standards. Two decades ago, I thought a merger would be technically feasible; now I am not so sure.
That was 20 years ago; much have changed since.
People talk about C's "separate identity" and (as above) C "has
different use cases, and serves a different group of users" from
C++. I have never seen C's separate identity clearly articulated,
nor have I seen articulation of fundamental reasons for there
being separate use cases. Such articulation might simplify the
discussions about which incompatibilities are deliberate and
essential and which are accidental.
For attempted characterizations of what C++ is and should ideally be, see
H. Hinnant, R. Orr, B. Stroustrup, D.
Vandevoorde, M. Wong:
DIRECTION FOR
ISO C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2000r2.pdf
On the other hand, I consider the value of compatibility obvious. Even in this thread, people have been surprised about differences in the standards.
Sometimes, my comments about compatibility are taken as attacks
on C or displays of ignorance. They are not. I built C++ on C and
few C programmers today have written a C program that doesn't
critically depend on some of my work. I was a friend of DMR and
still see BWK fairly frequently. The compiler used for the code in
K&R2 was written by me - and all the code was in the C/C++
common subset. However, I do not think that either C or C++ are
perfect, so I comment on flaws; such comments are not attacks on C
or C++ (though of course they could reflect misunderstandings),
but the first steps to potential improvements.