I'm currently teaching a Unity class at Parsons called "Building Worlds" -- and I'm treating it as my opportunity to get everything right and Solve All Problems in Game Dev Education... Obviously, the reality of the class is much more complicated, and ambitious teaching philosophies never really survive a semester intact.
But before I become bitter and jaded, here are the main principles / pillars I'm starting with:
0) Game development is not game design. The former concerns process, implementation, and engineering, the latter is the art of theoretically abstracting behaviors and relationships into something compelling.
1) Breadth. Everyone should know a bit of every aspect of game development, a "liberal arts" education in all facets of development, and everyone should be able to make a game entirely by themselves. All developers should have basic drawing / modeling skills, basic coding skills, and basic design skills. Of course, everyone has their specialties and interests, but the goal of game development education should be to produce independent, T-shaped developers who can see the big picture and collaborate when they need to. Don't specialize too early.
2) Emphasize dynamics before details. The specifics of Unity and C# syntax aren't important; in 5-10 years, there's a good chance that many developers won't be using Unity or C#. Rather, it's more important for developers to think in terms of design patterns and how to solve problems, and this conceptual understanding is much more important than remembering random API calls that you can just google anyway.
3) Give students a stake in the class. We devote at least an hour to informal presentation and discussion of homework, which is unusual for a technical class that's usually lecture-based. The idea is that students can pose approaches or problems to their peers, and their peers must reinforce their own knowledge in order to address each other. In doing so, we form a learning community and decentralize a teacher's power. For the second half of the semester, the lecture topics are generally open to requests.
4) Let people learn by themselves. People are going to learn Unity by using it and playing with it and practicing with it, and they learn much less effectively when you read a book aloud to them. Plus, you're wasting everyone's time. In general, try to lecture less and tutor more. Demonstrate things they can't easily glean from documentation, but let them figure out straightforward systems by themselves, e.g. Unity's Terrain tool.
5) Make students try new things. If education is a form of democracy, then does enrollment count as a "vote" for me as an instructor, to vest me with some sort of authority, as long as I'm not a tyrant? What do students need to know to become "well-rounded citizens of the game development world"? In this class, I'm making my students read some (or maybe all?) of a book called 10 PRINT, written by many smart people about the implications of one specific single line of code. It's part of an emerging academic field called "software studies." And someday, I won't have to put "software studies" in scare quotes.
6) Encourage failure. If game design teaches anything, it's that you're not going to get it right the first time or the fifth time you design something -- so embrace failure, and fail as quickly as possible. Evaluate students on their ability to analyze their process and ability to fail, not necessarily their "results." If anything, school should be one of the few safe places to fail with little or no real consequence, e.g. unlike AAA devs losing their jobs because you're a terrible level designer, or indie startups failing and closing down, etc.
Now, I don't think this approach is applicable to all classroom situations. (I'm teaching in a fairly affluent graduate design school that emphasizes critical theory.) Also, it's not going to work all the time, and some students will need more help. I'm definitely getting a reality check as I teach... but, again -- I'm failing as quickly as possible.