>>1,19
Wtf? Namespaces are not a hack. This doesn't result from non-descript names; virtually all widespread C libraries manually namespace their functions (png_, sqlite3_, etc.; a notable exception is zlib). They have to do this regardless of how 'descript' their names are. Do you really want all of libpng's functions available to your linker without the png_ prefix?
Namespaces would be nice, but I doubt it will ever happen. There's just no way to add it in a backwards compatible way; it requires name mangling. Anyway, having to add a short prefix to all your functions is hardly a big deal, and it doesn't hinder code readability too much.
>>3,6
C already has these things. Embarrasingly, C structs are better than C++ classes, because by forward declaring structs they allow real information hiding without causing massive recompilation of dependencies when a class changes.
There are provisions in the type aliasing rules which allow inheritance and polymorphism; this is how Python's object model is implemented. You can add function pointers for virtual functions, which is hardly more difficult than its C++ counterpart, and has many advantages; there aren't bizarre "member-function pointers", you have more control over how the vtable is assembled, etc. The only thing C doesn't do is automatic pointer conversions up the inheritance tree, which in my opinion is A Good Thing.
>>6
C string manipulation is a royal pain in the ass, hence the need for sane template library with common containers.
Um, epic fail? Why the fuck do you need *templates* for a string library? There are excellent string libraries for C that don't rely on templates at all, like bstring.
>>19
would greatly simplify the implementation and would introduce minimal changes in the language
Minimal changes, really? Didn't knuth say coroutines would require eliminating the concept of a stack? Seems it would take a shitload of work; converting all local variables of coroutine functions into thread-local globals, etc.
Even if the changes are minimal, no compilers currently support this, and no one is really asking for it. Adding it to C1X would actually hinder its uptake; people wouldn't bother with C1X because they wouldn't want to implement the harder parts like this.
>>19
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
A library for GC is not equivalent to built-in compiler-supported GC because the library doesn't know whether something is actually a pointer. If a random bit pattern happens to look like a pointer, the GC has to assume it's a pointer so the memory survives longer than it should; entire trees fail to be reclaimed because of this. It also prevents heap compaction because you can't move memory, which is a fairly critical part of modern GCs in performance-tuned languages like *shudder* Java.
That said, I don't think C needs GC. Memory management in C programs is not that difficult because it doesn't have exceptions, threading, etc. When you add a threading library things can get complicated, but threads are evil; they should be as isolated as possible to begin with. Freely available malloc() implementations these days are extremely fast and good at preventing fragmentation. Nothing says you have to use the platform's malloc(); it's easy to replace with a better one.
Personally, what I'd like to see is standardized syntax and required support for many function and variable attributes in use (not the dllexport/dllimport types, but rather the ones that affect code generation, i.e. structure packing).
I'd also like to see some commonly used, but technically illegal, idioms be standardized, like using a union for type aliasing.
What I *DON'T* want to see is microsoft's 'safe' versions of stdlib functions making it into the standard, like the incredible bullshit that is memcpy_s. Unfortunately this is apparently one of the standard committee's priorities for C1X.