The very use of the common misnomers "on the stack" or "on the heap" when referring to automatic or free storage respectively can cause a good deal of confusion when people find out that's not how things really work.
How are those misnomers? If you look in the Wikipedia page about memory management, dynamic memory allocation is described as "allocating portions of a large pool of memory called the heap". The C standard doesn't mention "heap" anywhere, but it doesn't mention "free storage" either.
The C standard doesn't talk about "the stack", but it also doesn't talk about "local variables". I am happy to talk about local variables in the context of the C language, and the implementation of local variables in a C compiler has to be a stack of some sort, at least if we are dealing with recursive functions. So I don't see the problem with calling this space "the stack" either. This stack doesn't have to be the same as the call stack, although that is the case in every compiler I have ever used, and when debugging some problems, it has been useful to understand something about the memory layout of these things.
I knew about the stack and the heap before I knew about C or C++, and I have a hard time using other terms. The mental pictures of the stack and the heap still serve me well, and when I ask my compiler to turn some piece of code into assembly language, it still looks like the stack and the heap are being used. I don't see why the terms used in the language description should be preferred.
I guess I just don't allow programming-language standards to determine how I talk about things that are larger than the programming language. For instance, a byte to me is 8 bits, but the standard specifies that a byte is whatever a char is, which could be something other than 8 bits. That might be the convention used in that document, but when I use the word "byte", I mean 8 bits.
While I am in rant mode, I call my .c and .cpp files "modules", and not "translation units", and I don't know anybody who uses the latter.