qsort(v, size(v), sizeof(int), my_cmp); // just works

Minor nit, but I'd always suggest promoting sizeof(*v) or sizeof(v[0]) here.

push_back(v, i);

This was kind of discussed in another comment, but I think the magical dereference of the first parameter is too surprising, and I feel like it might lead to some obnoxious compiler errors if someone puts a non-lvalue there.

You're in a language without references, and I think the problems that faking them cause are worse than the "disease" of requiring the user to type &.

find

You don't give an example of this, but looking at the code it looks like this returns a void*, and the same for other things. For example, I tried changing int *it = rbegin(d) to double *it = rbegin(d) to see if I was missing something and you'd get a compiler error, but because rbegin just returns void*, no error.

Personally, I consider this a fatal flaw of the technique vs a templating library that stamps out names that have types included (e.g. something like map_int_rbegin), though it may be fundamental to the design decisions that you want, like wanting to use unadorned names. But my feeling is that if you want that level of syntactic convenience, then... use a different language. You're using C, so accept what C does well and poorly, and this is not something it does well.

The company I work for has a lot of C code that uses container classes that are generated by preprocessor, and those get adorned names.

Another benefit of adorning your names like this is that I suspect that very very few substantive C programs would have no conflict with some of the preprocessor macros you name, especially something like size. I guess maybe those are likely to be benign conflicts in general... but enjoy the error messages and debugging experiences when common names like that get overwritten.

While I'm at it, it was only when I was writing a couple paragraphs up that I realized that int * is a weird return type to get from a map iteration, and I found that very surprising. Not wrong exactly, but if you're aiming for such closeness because it's what the STL does, it's... weird.

Next up stemming from this example is that... in terms of the concrete implementation, a couple of things give me major pause. First, even this single example has a basic bug in it, with printf("Number of elements: %d\n", len);. I'm not even asking GCC for extra warning flags, and I'm getting a warning about it. C is a serious and error-prone language. If you're this cavalier with getting types wrong and/or about going "yeah, this UB is fine", why should I have trust in the rest of your implementation?

Speaking of UB, all your __blah names are reserved to the implementation and also technically cause UB just by being compiled into a program. I'm a bit more sanguine about this one, but it's still bad form.

Another note of feedback that I noticed:

For node-based containers, always use next(it) and prev(it) to advance iterators — never it++ or it--.

These are bad names, especially if you're mimicing the STL. The STL also has next and prev but they do something different. (They return the following iterator, but don't mutate the argument.)

The STL also has a function that behaves (almost) like your next though, std::advance; that is the name you should use. You probably want to make that variadic too so that advance(it) behaves like advance(it, 1) which isn't supported by the STL, but I think that would be a good enhancement. I think you'll also want to come up with a name for advance(it, -1) (what your prev does), but nothing strikes me as super great.