If SQLite, along with its collection of external demos and aids, was purported to be a C++ library, then bug reports resembling "X is not const-correct" or "Y should be more const-accepting" would be taken and likely acted upon.
What I am saying (in post #2) is that you could rewrite ext/misc/carray.{c,h} to make it more const-accepting with no changes any more severe that a few const_cast's here and there.
I appreciate that casting must be done judiciously. I also know that one can write C++ interfaces with the virtue of never requiring const-casting by clients at the cost of significant LOC increase.
You might worry that SQLite's [Pointer Passing Interface](https://sqlite.org/bindptr.html), given a non-const void *, is going to modify whatever it is that the pointer references. But if you read the carray code, you should be able to alleviate that worry for the pointer's final destination. As for its passage, I can assure you that the library code will not even dereference the pointer, let alone write through it. To the SQLite library, it is an opaque value which just happens to share the same sizeof with data pointers and has a "type" commonly used for data pointers because that is the C way of making/passing objects of that size.
That covers the pragmatic aspects of achieving the const-aesthetic you seek.
If you are a const purist, or seek to satisfy that crowd with nary a const_cast\<...\>() in sight, then I suppose you will need to expand that Pointer Passing Interface. You could even templatize it at the same time. It will be a thing of beauty, somewhat less Lite but highly pleasing to some who value that sort of thing.