Some of your requests will never happen, and with good reasons, I'll explain:
e) Fix the macro language so it is type safe
The macro language is not part of the c++ language. As far as I know, Bjarne would have loved to get rid of it entirely, but it was kept to help maximize C compatibility.
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
16/32 characters are fully supported in c++11, see char16_t and char32_t. I could be wrong, but I don't think I've seen a language which has 24-bit characters. It would likely be inefficient to support anyway since I'm not aware of any architectures which 24-bit access is properly aligned.
i) Fix the darn grammar so that compilers accept UNICODE source
Many compilers already do support UTF-8 in source code. But I do agree that this should just be standardized across the board.
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Why? So you can have a function named () instead of pi()? This strikes me as something which would just make it harder to read.
k) Add a proper exponent operator
Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.
NO. You will probably disagree, but this is part of the *strength* of both C and C++. By allowing something to be undefined or implementation dependent. The standard is allowing the compiler to choose the most efficient code to emit. If the standard were more specific in these places, we'd have a "one size fits all" solution which would be optimal for some architectures and very much sub-optimal for others. Better to let the compiler writers who know the arch best to decide these things.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
When is C++ going to add reflection support?
It probably won't because it's not well suited for how things work in the language. Here's (part of) the problem. With templates and optimizations, often there can be 100's of types created during compilation which are independent but get optimized away to literally nothing when finished. Should the compiler waste time and space generating reflection information for types which simply don't exist at runtime? Should the compiler emit reflection information for each and every template instantiation of std::vector that your program uses? You can't do one set of reflection's for each template, because different specializations can have different members! It spirals out of control really fast. Personally, I would not be apposed to an opt-in reflection system. You use some special syntax, let's say:
reflect class T { };
or something like that. Which would then add extra stuff to the std::typeinfo object associated with that type. So that way you could in theory do something like this:
typeof(T).methods(); to get a list of methods for T, IF you have opted in. But I don't think that will happen.