That seems too nitpicky to me. You can use those definitions if you like, but it's not the common usage. To most programmers those terms are synonyms. In my experience, people trying to be precise about architectures like node.js use the term "asynchronous" and not "concurrent".
Calling node.js concurrent obscures the important fact under discussion: namely that it won't scale beyond one CPU in a world where 8-core servers are routine.
The distinction between parallelism and concurrency is extremely important. The guys who wrote Real World Haskell did a good job of explaining it here http://book.realworldhaskell.org/read/concurrent-and-multico... (explanation has nothing to do with Haskell).
In essence, concurrency has to do with systemsy stuff- how to do things that might overlap without causing problems (race conditions). On the other hand, parallelism is about breaking a problem into smaller parts and attacking it in pieces. The problem with most languages is that they require the programmer to worry about both at the same time; however, languages like Erlang alleviate most of these problems, the biggest of which is shared state.
You're arguing semantics: about words, not meaning. My point wasn't that this isn't interesting, but that the jargon you are using (and that book is using, for that matter) is revisionist and confusing. That's just not what "concurrency" means to most working programmers, who have used it for decades to talk about (ahem) "systemy stuff".
Rewriting language via blog posts doesn't work (c.f. "hacker"). Doing so as a way to, frankly, cover up a huge design flaw in your favorite library just seems dumb to me.
Seems too fine a point for me too. The number of CPUs doesn't matter, that's up to the scheduler. What limits the the scheduler are coordinating shared resources. That includes CPU, locks, memory, disk, network, IO, etc. The multi-node issue doesn't seem that much of a problem in that you can start a node.js process per core. There's very good performance doing this for MySQL, for example.
Calling node.js concurrent obscures the important fact under discussion: namely that it won't scale beyond one CPU in a world where 8-core servers are routine.