I suspect that the “code sharing between solutions” judging point basically amounts to “put the shared code in a psm1 file.” for maximum points. Because all of your code is in a single ps1 file (for both the “manager” and “project manager” solutions), maybe they didn’t treat it as sharing code between solutions, even though they both called some of the same functions. I’m also fairly sure that the intent behind that event was for us to write two separate PS1 scripts (one for the manager, one for the PM).
I haven’t actually tested your code, but it looks like you’re correct about handling odd numbers of names, except for maybe one thing: you’ve forced the person to be paired twice to also be a Primary, which wasn’t mentioned in the requirements doc. They may have deducted the points for that reason. However, as a bit of a karmic balance, you’re using % and ? aliases in your code but still got the full point for “no use of aliases or truncated parameters”, so it probably worked out to the same final score anyway.
Your algorithm is a little bit hard to follow (here’s where some comments might have helped to improve the clarity), but once I caught on to what you were doing, I like it. I used recursive functions to handle the backtracking; yours works with just a loop, which might technically be better when handling very large pools of names (recursion might hit a stack overflow, or whatever the PowerShell equivalent is.)
Based on a very quick read through the entries when they went public, I didn’t see very many solutions that properly backtracked and tried different combinations of pairings. It’s easy to generate a random pairing that doesn’t violate history rules, but what happens when you get to the last two people left in the list and they’re not supposed to be paired? There were some that used the “re-randomize and try again” approach you mentioned, but that could just run forever if there’s no legal combination of pairs, which can happen if you have a very small pool and too many primaries (8 total names, 3 primary, history depth of 4, for example; the 4th or 5th execution will fail every time.)
Anyhow, for future events that have two separate tasks to be performed (such as the “Create folder tree and assign permissions” and “analyze and/or fix permissions on existing folder tree” tasks in Event 3), I’d suggest breaking those out into their own separate PS1 scripts, and creating a PSM1 module for any code shared between them. That should get you full points for the “code sharing between solutions” item.
Edit: In fact, out of habit, I even split our code into a PS1 script and a module in Event 2, which didn’t technically have two “solutions”. I tend to put the “Cmdlet” style functions into a module (those that accept and output raw objects), and put the user-interface code into a PS1 script; any code that’s responsible for formatting, displaying, importing or exporting data goes into the PS1 script, as well as any prompts for input, etc. I’ve seen this approach described as “tool making” in the module and “controller script” for the PS1 file before, which seems like as good a description as any.