Inconsistent messaging around adopting unsupported for security reasons projects

Problem/Motivation

Quick glancing it appears to me some of the modules that were included in the recent SA blast did not have any public issues to review (or if they did it was not obvious the issue was referring to them)

Currently the documentation about what to do around a project that has just been announced unsupported appears to be somewhat contradictory. It appears to me the document was written that the actual security issue is public at the time the SA is released (which would make sense given that once a module is unsupported it is no longer entitled to private disclosure) and sometime after the document was written with those conditions the policy was changed that the security team would hold onto the issues privately.

The message atop projects taken from marking a project as unsupported for security reasons appears to imply that a security issue will be public and than contact the security team for a review.

<li>File an issue in the queue with a patch to fix the module and then <a href="https://www.drupal.org/security-team">contact the security team</a> to have your version reviewed and the project handed over to you following the <a href="https://www.drupal.org/node/251466">unsupported project process</a>.</li>

The Process for taking over abandoned projects Becoming owner of a project that is unsupported for security reasons implies in most cases the content will be public (but provides a fallback method to get access to the issue from the security team)

For most modules, finding the issue should be easy. If you are unable to find the issue, you can email the team and the team may give you more information about the issue, if and only if you are willing to commit to maintaining the project.

While a message from a security team team member on Slack appears to imply if the issue isn't public one should just try and harden the module any way they can (without knowing the actual true fault.) (note: this was sent from someone not at their desk so It is likely not the clearest, but it goes towards my point that messaging is not consistent)

In order to take over a module, please follow the directions from the SA links. If you can’t find the exact security issue in question, suggest a security hardening of any type. The project applications issue queue will be ignored for 30 days in favor of the what is laid out in that linked doc.

Which I suppose is a good way to test if an individual has the ability to discover vulnerabilities however no where is it declared explicitly in the procedure that this is suppose to be a test (and really is this the right time to be testing someone who is already vetted who is trying to secure a module?)

Additionally what does it mean that the application queue will be ignored for 30 days in favor of the policy? Does the policy expire at 30 days and it becomes available to become a maintainer without any requirement to fix the issue?

Next Steps

I'm willing to try and take a round at making these more consistent however before I can do that can someone specify exactly what the intended process is suppose to be?

Is a public issue suppose to exist immediately after the unsupported SA or is it suppose to remain private?
Will the team come back in 30 days and release it or will they never release the issue unless someone is volunteering to maintain?
Should an individual wishing to volunteer try to contact the security team to obtain the known issue or should they just fix any small security issue they can find? (and what if no obvious one exists?)
etc.