There weren't specific blockers for stabilizing features guarded by `experimental_training`; I just wanted to make sure we've kicked the tires a bit before marking it as stable, since I was concerned that we might need to make some backwards-incompatible changes to it (and I think I have). I was planning to remove the need for the `experimental_training` feature before the next release. If you want to submit a PR to remove `#[cfg(feature = "experimental_training")]` everywhere, I'll be happy to review it. I don't want to directly remove the SavedModelBundle::meta_graph_def field (if that's what you're referring to), because that could break users, but we could mark it as deprecated.
We are using GitHub issues for bugs and feature requests, although perhaps not as consistently as we should. Are you suggesting using something like labels or milestones to track which specific issues are expected to be in each release? For this to work well, we'd need an actual planning process, and there currently isn't one. One difficulty is that we can't dedicate a certain amount of time to work on each release, because to the best of my knowledge, contributors (including myself) are working on this on a best-effort basis. I'd like to get a release out soon, but we can try planning the next one. I'll come up with an RFC for a hopefully lightweight process.