To me, software engineering is about creating larger-scale software that adequately meets the need, and doing so as efficiently as possible - which is not to say that it's efficient. When there's six steps in the communication path between the need and the programmer, how do you minimize the amount of time the programmer is implementing the wrong thing? This is a far bigger problem than choice of language or algorithm, but I doubt you'll ever find it in a CS curriculum. I might even say it's the fundamental problem of software engineering - or perhaps of software engineering management.

Along those lines, they should teach clarity of writing technical information, and ability to read less-than-stellar technical information.

"That adequately meets the need" - that's not perfection. How do you evaluate and triage bugs? How do you manage the bug list? For that matter, how do you even know what bugs you have? Testing strategy should be part of a software engineering curriculum.

Working with a version control system. They might get that in a CS degree, but probably around the edges and by accident. For a software engineering degree, they should get it in some depth and on purpose.

I don't know what I'd cut to make room for that kind of thing. But I think that kind of thing needs to be there for an actual software engineering degree.

This is already the case with classical engineering degrees. The majority of undergraduate engineering coursework is science, calculus, or some form of applied mathematics specific to the discipline you're majoring in.