I tried this once after AP CS-A and...it didn't go very well because the kids needed more structure. If I was still in the classroom I would now try the following:
First of all, I would put students into pairs who are planning to use the same language/environment. They can make independent projects, but they should also be expected to be thought partners and help each other. Second, I would propose two weeks of planning (which might include investigating other languages). Check out the Stanford Design School resources for activities around design thinking: https://dschool.stanford.edu/resources/. I would do some of those activities to get brains churning since students should be programming with a purpose toward a goal. Also, this will help them choose their tool.
Also, they will inevitably not finish or get (anywhere) close to what they thought they could do. So having a design plan is at least an artifact you can grade, and you can also ask students to make small lists of task from their design plan to prioritize to work on. So in the end I would have students turn in (1) design plan (2) checklist of tasks showing how far they got (3) actual program they wrote.
Best case you have some "demo days" at the end of the course for students to show their stuff. If you do that, I would also do a dry run with their thought partner a week ahead of time so students can see what they're up against. I would actually have them do a weekly progress check-in with their partner once a week.
As for a rubric - make it as much about the design, progress, and demo day as possible. You do not want to get stuck in June grading programs in variety of languages that you might not know, and probably don't work anyway. I would honestly mimic the Create PT to some degree -- have students submit their code, of course, and also a video of them using their program. I did that, and it worked. What I said was: (1) you need to make a 60-second video of you using your program (2) provide instructions for me about how to run your program, and what to do to see EXACTLY what's in the video (3) Make a giant obvious comment in your code that highlights the portion you are most proud of having written, or you think is the most interesting/important part.