I see that there are changes to API between Proxy 3 and 4. Today's C++ package managers deal with diamond dependency resolution issue by forcing one specific version across all dependencies, this is the case for vcpkg, conan and CPM (it's not the case for FetchContent_Declare though). It means that if:

• library A depends on Proxy 3.3.0
• library B depends on both Proxy 3.3.0 and library A
• library A updates Proxy to 4.0.0

then the author of library B only has choice between:

• locking library A version to the one before Proxy update (missing out latest features from library A)
• or updating its own usage of Proxy to work with Proxy 4 (causing it to potentially no longer compatible with Proxy 3; the breakage then propagates downwards for any consumers of library B).

Neither are good options.

It's not ideal to require updating every facade definitions for non-trivial size projects and all of its dependencies at the same time, as Proxy stands very closely to being a core language feature (such feature, the polymorphism, would have been implemented into the core language for almost any languages other than C++). This is basically a hard split.

Unless this library is intended purely for demonstration of standardization of a C++ feature (which I think it's more than that), I recommend making changes before the release of Proxy 4 to make sure that:

• The project is designed so that it's possible to create a new Proxy 4 package, in parallel with the existing Proxy 3 package. This means renaming the project name, CMake target name as well as CMake *-config files to contain major version info (e.g. proxy4).
• #include-ing or import-ing [1] both Proxy 3 and Proxy 4 works. This means either moving the pro namespace to pro4, or creating a new nested namespace v4. the user could manually import the symbols into pro namespace if desired (e.g. namespace pro = pro4; / namespace pro { using namespace pro::v4; }).

This does not mean that Proxy repository should keep all the older implementations in the current main branch indefinitely for compatibility. That task is shifted to package manager instead (for instance the vcpkg port proxy can be left as is, and it will fetch Proxy 3 instead).

[1] Note that Proxy 3 doesn't have modules support. But addressing this theoretical scenario makes it possible for a future Proxy 5 to be compatible with Proxy 4 when importing both.