I like the spirit of these policies. I think they need a little wording work. Comments inline.
Who is responsible for generating these? The mechanism or responsibility should be made clear.
I clicked through a doc -> thread -> doc to find even some details. It looks like manual run of a gradle command was adopted. So the responsibility needs an owner, even if it is "unspecified volunteer on dev@ and feel free to complain or do it yourself if you don't see it"
I think the big "should" works better with some guidance about when something might be an exception, or at least explicit mention that there can be rare exceptions. Unless you think that is never the case. If there are no exceptions, then say "must" and if we hit a roadblock we can revisit the policy.
How is "significantly outdated" defined? By dev@ discussion? Seems like the right way. Anyhow that's what will happen in practice as people debate the blocker bug.
With Maven, this involved a lot of boilerplate so I never did it. With Gradle, we can easily build a re-usable rule to create such a package in a couple of lines. I just opened the first WIP PR here: https://github.com/apache/beam/pull/5570
it is blocked by deleting the poms anyhow so by then we should have a configuration that works to vendor our currently shaded artifacts.
So I think this should be rephrased to "should be vendored" so we don't have to revise the policy.