Why do you consider old libraries such as string.h for ASCIZ arrays to be in the "heart of the language"?
I don't. I consider string.h to be a library for the C language, cstring on the other hand I consider to be...well a library for the C++ language but not the language.
Might I suggest that you read 5.2.3 Explicit type conversion (functional notation) in the C++ standard (to my knowledge it is not valid C but is valid C++).
No it's not. int(something) is a cast of something to int - you're right with that. But it doesn't work with signed int because the int part alone is already a token, so it's "signed" before "a cast to int", which is invalid. Same with int*(something) - for the compiler, *(something) is application of the dereference operator, so it's actually int whatSomethingPointsTo which is also invalid C++.
Ok, my bad... I was just looking at it as the functional notation was in question.
So functional notation requires a simple-type-specifier, signed int is a simple-type-specifier however to help the compiler you would have to put it in parenthesis or just use signed.
As for casts in general, A(arg) is the same as static_cast<A>(arg) where valid, while (A)arg is the dreaded C-cast (personally, I am not for banishing it: things like std::addressof written without C casts are a pain to read)
Ok, So I consider a valid combinations of simple-type-specifiers to still be a simple-type-specifier but am willing to concede that someone on the standards committee says it is a combination of simple type specifiers, and is not itself a simple type specifier.