It'd be interesting to teach a semester-long course building up a single complex application, and to require each student to swap their source code with another (randomly selected) student for each new assignment.
They do that at my university for one of the project courses (where teams of 5-6 build a single application for one semester). Later on they make teams trade the code with eachother. I'm not there yet so I can't comment much.
My program is computer engineering, not CS, though.
The first three are so important and so often glossed over. It drives me crazy when I hear classmates look for the easy way out or avoid a problem because it's "hard." There's no professor in the real world and if something's hard, tough luck. It's important to start learning to teach yourself as early as possible and during school is a great time to do it. Learning to independently handle difficult problems is something best done in a nurturing environment, not somewhere like a job where you have more to lose.
How to ask a question.
How to communicate.
How to come back to a program you've written after a year. Or after ten.
Distributed source code control.
Incremental development.
Integrated debugging. Planning for failure. For support.
Finding and using libraries or frameworks.
Backup.
Source code archeology; how to understand and extend and maintain complex applications.
How to work within a team of programmers.
Upward-compatibility and code longevity; the multi-edged sword of an installed base.
The game (tools, operating systems, languages) changes at least every five to ten years, or more often.
You're an integrator first, and a programmer second. Or third. When you need to.