It was obvious that PR #36 would break ABI. In this PR, it's not obvious, but
I suspect that one or two of the changes can break ABI, replacing a non-inlined
method with an inlined one, thus removing a symbol from the library file.
I may take the time to investigate further some day. Unfortunately, even if I find
that all changes preserve ABI with the compilers I have easily available (gcc and clang),
ABI might break for someone using other compilers.

A general comment concerning your many PRs: clang-tidy is too nitpicking.
We don't have the ambition to make clang-tidy happy with all checks enabled.
This kind of micro-fixes aren't worth the trouble, especially not when there's
even the slightest risk of breaking ABI.
If you want to make contributions that make a difference to users of libxml++,
you would be very welcome. You could for instance fix bugs (there aren't any known
at the moment) or add useful functionality. It's possible that there are functions
in libxml2 that haven't been wrapped in C++ code. Other than making it possible to
build with Meson, I have spent very little time on libxml++ the last few years.
I intend to spend even less in the future.

Only the second commit would have an issue like that.

There is a good old rule saying If it ain't broke, don't fix it.
Your PRs do just that, they fix (or you could say update) working code.
In most cases such changes are not worth doing. There are cases where it's worth
doing. For instance override is fine. It means the compiler can check that a
virtual function is really overridden. = delete is clearer than private
methods not being defined. But generally, leave old code alone as long as it works
and no compiler complains. New code is another matter.

Sorry, but I don't want to merge this PR. I find most of the changes unnecessary
and uninteresting. If you want to, you can keep it open and hope that another
maintainer in the future has a different opinion.

PRs that fix bugs or add new useful functionality are always welcome.