> bounds checking enabled by default for arrays and strings

You can make your own explicit bounds checks, or you can use valgrind (which, just like any type system, can understand only simple situations).
You can use C++ which actually does allow you to do bounds checking by default, if you're into such things.

> - real enumerations that aren't implicit converted into numeric types (fixed in C++11, if one bothers to use enum classes)

> - enumerations can be used as indexes (C++ can work around this with enum classes and some boilerplate templates)

> - ability to actually define subtypes that are enforced by the type system (C++ offers this, provided one does the required boilerplate class/template code)

These are total non-issues in practice, since treating them as integers is usually what you want (you almost always want to support some light arithmetic on them, you want to store sentinel values sometimes...).
Furthermore (as you say) C++ allows you to treat them as separate types.

> most data conversions must be done explicitly

This is the same with C, except for integral types where though you need to turn on warnings to avoid implicit downcasts of integral types with some (most?) compilers. For upcasts, implicit is what you want.

> memory allocation by default doesn't require doing math with data sizes (C++ as well, yet there is too much malloc()/free() pollution in C++ code bases)

That's FUD, if you do memory allocation - of course you need to compute the number of bytes you need.

If you do "new Foo[count]" you're likely doing it wrong anyway, just like if you're calling malloc directly.
To equate memory allocation with malloc (or syntax sugar in fancy object languages) is WRONG.
malloc() is a stupid default allocator, and you don't know
what allocator you're getting if you don't provide your own. Good system performance often requires writing (simple)
custom allocators instead of using malloc which has to deal with random allocation sizes, allocation patterns,
and multiple threads.

Whether using your own allocator or not, it shouldn't be too much to expect you to write a single line like:

#define ALLOCATE(type, count) ((type *) do_alloc(sizeof (type), (count)))

Or even

#define ALLOCATE(ptr, count) (ptr = do_alloc(sizeof *(ptr), (count))

Now tell me, why exactly is "new Foo[count]" safer than "ALLOCATE(Foo, count)"? Or just do this minimal boilerplate by hand, this is not a practical issue unless your
code is very badly factored (good code requires only few allocations).

> no need to deal with pointers for out parameters, thanks reference parameters, which even in C++ there isn't any guarantee they aren't null, even though that would actually trigger UB)

This is not a problem at all in practice, and anyway, if you need a lot of that you're doing something wrong. I very much like that C keeps it simple and you always see what happens. This is unlike Pascal and its Objects extensions, where it's impossible to see which data you're actually mutating because there are like 10 different "adressing modes". For example, dynamic arrays in Pascal can be assigned to other variables (or passed through a function parameter), and they will share memory, but only until one calls SetLength() on one "reference" at which point a Copy-on-Write is happening and they split lifes. This is not only not useful but extremely confusing. And the whole object extensions to Pascal (I can speak for Delphi) are built in that way - trying to not let the user see the complexity of what they're doing - which works until it doesn't, which is when you're dealing with extremely difficult to debug problems. Frankly Delphi ecosystem is a mess because it's a set of layers where each time they tried to be clever and add another philosophy-driven set of classes with implicit behaviours on top that was supposed to fix the previous layer's mistakes.

> - if one wants to do crazy C like code, all the necessary gear is available, pragmas to turn off bounds checking, pointer arithmetic, unchecked casts, unions, mapping variables to explicit memory addresses, pointers to callbacks, it is everything there in the package. The original bare bones ISO Pascal wasn't no longer relevant in the mid-80's, unless the teacher didn't knew any better.

This is why I took issue - you can't have both low-level bit twidding and "memory safe" programming. At most you can have a language that lets you choose between one or the other in a rather integrated system, but then you're still dealing with this abstraction gap, and having to traverse it constantly is not pleasant.