I worry that this is going to add too much churn for the team. What happened to “if it isn’t broken, don’t fix it”? It’s fine of course to experiment without committing PRs – like when you found that _statistics was significantly slowed down. But in general I worry that this is just going to create a stream of PRs that have low priority, that few people care to review, and that will increase everybody’s frustration (not just yours) with how hard it is to get people to review PRs.
“Eat your own dogfood” is a fine idea, and I think it’s great to apply it to new modules. Just like we sometimes add annotations to new code, despite our general reluctance to add annotations to existing code (especially stdlib code). I feel the same ought to apply here: let’s not try to “fix” existing modules, because they aren’t broken, and ultimately there is no reason for the stdlib to use the limited API.
Related, what’s the point of making Argument Clinit support the Limited API? I thought it was an internal tool that we’re not maintaining for 3rd parties. Was there a discussion about a change of course somewhere?