First, some caveats come to mind. The difference between languages isn't primarily syntax, even languages in the same paradigm family. Once a student has a solid basis of programming in a single language, say Java, they have developed a way of thinking about transformation of problems into solutions. They have ways to assure that their programs are correct and complete. One hopes, at least. Changing to a different language requires that they learn to think in a different way, whether it is small or large.
I once considered applying for a job where the focus was to be on languages (my specialty). They wisely specified in the call for applications "Principles of" not "Examples of".
The basis of my suggestions, following, is to focus on the principles, not the examples. And the principles involve ways of thinking, not syntax. It is pretty common for people moving from one programming language to another to just write in the old style. A Python program that is just "misspelled Java", isn't really a Python program. It isn't pythonic, in the jargon.
In a university curriculum there are often (or were) two courses devoted to languages: Language Principles, and Languages and Compilers. I taught both of these for many years. By the time students take the first course in the sequence they are well grounded in at least one language and have likely seen a couple more, mostly in passing.
I think you are correct in wanting to stay mostly away from other OO languages, except:
The difference between Java and Python (or Ruby) isn't the syntax. It is that Java is statically typed and the others are dynamically typed. If a Java program compiles (and you haven't used casting incorrectly), then it is type correct and will not fail for type errors when running. That isn't true for a Python program since the (still strong) typing is done at runtime, not at compile time. So, one major problem for the Python programmer that isn't faced by the Java programmer, is what tools and techniques (ways of thinking) does the Python programmer need to employ to assure that the (compilable) program they write will actually run to completion.
But, if you want students to learn to think in a different paradigm than what they learned first, you will need to give them time and experience. I think that six weeks per paradigm is probably sufficient if it is done well and fairly intense, focusing specifically on how to think like a whatever programmer.
Some possibilities for languages after OO.
Scheme (Racket) or Standard ML (aka SML). A minor point, but some functional languages use eager evaluation of function arguments (like Java) and others use lazy evaluation. The programming style is a bit different for these two cases.
Modula 2 (or Dijkstra's presentation language) or Oberon. These are for pure procedural programming. Top down problem decomposition, solution of simple problems as procedures, bottom up solution integration.
SQL and the underlying Relational DB theory that underlies it. A really different paradigm. Recent versions are Turing Complete and can be used (awkwardly) as general purpose programming languages. A chance to explore Turing Completeness and maybe even Turing Machines.
Some concurrent programming language. Maybe Rust, which is both modern and a C replacement, Erlang. Or even a data flow language like Swift -- note: That isn't Apple's language of the same name.
Some simple and uniform Assembler Language (not Intel). You need an emulator, though. A simple memory model. A uniform Register set. Both pdp-11 and MC68000 fit the bill-- more --
Prolog Logic programming where the program is descriptive, not algorithmic. Actually, SQL has that characteristic also. The algorithms are (almost) all built in.
Perl or bash scripting language
Lots of choices - the list isn't complete at all.
Late in your sequence you could have students work in small groups to produce a report (with examples) on some language of their choice, taken from a list that you supply. You could use a lottery system of some sort to make sure each group has a different language. The language can be wildly different, There are a lot of possibilities. I would probably include R, Self, Processing, Forth or Postscript, Bash, ... -- more -- for my own list. You could also let them make proposals for languages not on your list if they can give you a (written) reason for another language. Don't let them misspell Java, of course. And make sure a processor is available to them for any language.
I suggest that the last few weeks (you say six week terms) would be to summarize what has been learned in the previous segments and make some things very explicit. For example, dynamic v. static typing. You could also give them an idea about what a compiler might look like for a simple language, in particular the separation of lexical, syntactical, semantic, and optimization components of a compiler. A good source for the latter (instructor resource) is Per Brinch Hansen's, On Pascal Compilers. You can probably find a copy in a good academic library. Another good source (again, for the teacher) is David Gries's The Science of Programming. The latter book does an interesting thing beyond its stated purpose, which is to you how an imperative programmer should think in terms of pre and post conditions while developing algorithms. It uses a simple language for exposition that is the same as that used by Edsger Dijkstra in his scholarly papers. A compiler for this language is, like the Hansen book, quite accessible.
You obviously can't do all of this. Nor would a university course. But, I would use at least the following in developing the course.
Choose languages from different paradigms and focus on that - the deep semantics, not the syntax.
Think about all the variations open to the language designer and try to cover as many as you can. Static v. Dynamic typing. Concrete v. Abstract syntax. Strong v. weak typing. Garbage Collected v not. General purpose v. special purpose. Many v. Few abstraction mechanisms. -- more --
In going from one fragment of the course to the next, I'd think about how different the next language is from the previous. Scheme is very different from Java (no syntax, no variable state, dynamic typing,...). SML, at least has syntax and a very interesting type inference system that permits typing at compile time in a functional language.
Summarize at the end. Provide room for a lot of discussion. Have the students write reports and not just programs.
