Why don't you precisely define what's wrong with it? In its most basic form, it allows a RS to easily and quantifiably compare a group of individuals. That's ultimately what a screen board is, right? We're managing a finite amount of opportunity based on a set of standardized subjective assessments.
First, the stack rank. A summary group doesn't need to be set up against each other. They may or may not ever compete against each other in the same tank. So it answers a question no one is asking. The board isn't convened to answer how LT X compares against LT Y of VAQ-69. The board is convened to answer how LT X compares against all the other LTs in the tank at that time. Yes, I realize that the savvy RS can use distance from their cumulative average to break this out. Yes, I understand that the RS can use the writeup to explain this. Yet when people are talking about whether someone broke out or not, it's not "wow, this person got a really great #2 EP or ranked MP, but that's cool, because the ready room is baller." And we've discussed earlier in this thread that the RS's hypothetical option to not give anyone the EP in actuality amounts to a headshot for the whole summary group. So now you could argue that in reality, if not in theory, we've created a system where someone has to get that #1 ticket, even if they're just the least-putzy putz in the room. So why bother?
We're betting that in the event of a logjam at the top or a clownshow, a) the RS will be savvy enough to write good paper, b) the briefer will be savvy enough to convey this to the board, and c) the board will take note. I've never been in a tank; maybe all this happens every time, puppies and rainbows fall from the sky, and no one screws up ever. But in my mind, this introduces a lot of needless complexity. The solution to this is to can the stack rank. Allow the reporting senior to explicitly tell the board how that officer ranks amongst ALL the officers of that grade they've served with. "This LT is in the 95th percentile of all the LTs I've served with in my 18-year career. Promote accordingly." Boom. Done. That is the question that needs to be answered when the board meets. So create a FITREP that directly answers that question. No robbing Peter to pay Paul if you have a group of rock stars. No inadvertently crowning the king or queen of schmucks. No tea leaves necessary.
This leads into the second problem. Summary group sizes. An officer's actual fitness or non-fitness for promotion has everything to do with their skills, personality, and experience, and precisely fuck-all to do with the number of peers they serve with. This is another artificiality we force on ourselves by using the summary group stack-rank as a discriminator. A 1 of 1 ticket shouldn't have any more weight than a 1 of 45. What should matter is the assessed promotion potential of that particular individual. The solution to this problem is the same as the first one, and it also eliminates a whole category of bullshit detailing games.
Finally, ticket length. A 12-month EP is viewed as a bigger feather in one's cap than a 10-month EP. I'll grant some validity to this one, because it's one thing to perform in a challenging job for a long period of time, and another to muddle through and leave right before the wheels fall off. But again, factors outside the individual's control rear their ugly head. We shouldn't have to shuffle people in and out of billets for the FITREP 500. We should let the reporting senior assess them individually, and if time in a key billet is part of that calculus, fine. If the board wants to see experience in a given billet, fine; put it in the precept and let the reporting seniors manage their people accordingly.
I've said it before, and I'll say it again. When it comes to FITREPs, I think the Marines have it wired to a much greater degree than we do. Independent assessment like I just beat to death, and two sets of eyeballs on the end product. I can't think of any other area in Naval Aviation where "good enough" is seen as OK. Yet that seems to be all anyone has to hang their hat on about the current system. If you're building an aircraft, you design it to fly beat-up, battle-damaged, and able to handle a certain amount of EPs and still bring the crew home. If you're designing a piece of software, you don't just stop before you've addressed error handling, input error, and guarding against hacking. You find the corner cases and make the system deal with them gracefully. And when you find bugs, you patch them. You don't just say "it's good enough."