I’m not sure that this is the case. I think there is an underlying design issue that will always lead to unsatisfactory outcomes. This is obviously not something I know for certain but there is some evidence to support this in C22 (and C24 shares the same code base). For instance, I would often get into positions where, when I was bowling, the batter would start edging every delivery until they were caught…this could span two overs but the implication was that the game had calculated that it was time for a wicket and it would conspire to make that happen. It didn’t really matter what I decided to bowl or how well I executed it. This is what stops it being a game…it is an entertainment, perhaps, but not a game.I have always said the core gameplay and the foundations are very solid. If it's gets some love it will be a cracking game of cricket!
What I would like to see are three distinct phases in a delivery, none of which are dependent on the other for their outcome. So, when bowling, the first phase would be the delivery by the bowler which should trigger a physics simulation of the ball. The second should be a batter responding to the physics, based on the game context, previous delivery knowledge, their skill and their preference to, say, play on the on side etc. The third should be the way in which the fielders respond to the batter’s shot or attempt at a shot. This would allow for things like batters being bowled leaving a ball, getting wickets with bad balls, setting a batter up, bowler getting punished for being too predictable or wayward, batters taking more risks if the game required it (e.g. final over of T20 or falling behind the run rate) etc. As it stands I think outcomes are predetermined without any real de-coupling of the actions of the bowler and the batter.
Just a thought. I could be wrong.