Earlier quoted context omitted.
The computer science definition of concurrency and parellelism are different that what you're explaining. In CS, a program can only be concurrent. Parallel is to do with how it's run, and the hardware. A concurrent program, is still concurrent even if it's run on a single core, whereas to be considered parallel, it must be running on multiple cores/processors/machines/etc. at the same time. One way to think of it: If…
When I was in computer science classes in college, "concurrency" was defined as multiple processes running at the same time on multiple processors. You could not have concurrency with a single core. If all you had was a single core, then the best you could hope for was "pseudo-concurrency," because it is impossible to run two things simultaneously on one core. When did this definition change? Your food metaphor doesn…
The words "concurrency", "multi-threaded", and "parallel" each have different meanings. You can have a program that is multi-threaded but which does not maintain concurrency ie. the output is dependent on race conditions. This is usually, but not always, a bug.
Your confusion stems from the fact that most people do not care about the distinction. You usually don't care about concurrency unless you plan to actually run things in a manner which is unordered. Thus when the theory says "concurrency" you think "parallel". Technically speaking you're wrong, practically speaking your mistake usually won't matter.
As a final example consider a single-core computer running Windows with multiple processes running a myriad of services and programs. At any one time only a single process can run on that single available core, but in practice they are running "at the same time", because the system is implementing a model of concurrency allowing it to schedule and execute the different processes out-of-order.