Regarding the no version state: My opinion is that this should be used for issues that are not actionable, not because of external issues (need prerequisites done, needs 1.0 first etc.), but because of issues with the issue itself: insufficient information to categorise it, triage not happened yet or still in progress and so on.
Every other issue should have a version number assigned to it, because that means it will appear somewhere on the roadmap and given the right circumstances a developer can pick it up.

Technically, anything is actionable - the action can be to do research, have a discussion, set it to Feedback needed, reject the issue due to lack of feedback or because we think it can't reasonably be done.

I'm not opposed to having a list of 'ready to code' issues somewhere, but I don't think versions/milestones are the right way to do it. It would be nice if we had tags.

It sounds like you all have a bunch to figure out on the developer end. My only input is that you can't change human behavior, you can only guide it into the outcome that you want. This makes the decision to remove adding a version to the bug reports good. Bug reporters should only have control over things that aid them in giving the devs more info on fixing the bug, everything else is a distraction. However, people are still going to be confused as to why certain things are being overlooked (in their eyes). Clarifying the way decisions are made on the wiki will help, so will giving the devs a united way of approaching triage and bug squashing. I'm sure most users won't care one way or the other as long as overall progress is being made, but whatever solution you find it might be helpful to think of the whole thing as a PR process. My approach is that everything visible to general users is essentially a PR problem. Less confused users will be less annoying!

@raevol I don't like spending a large amount of time on this stuff and (as I have mentioned before) we have to do it again after 1.0 anyway, I prefer to do as little as possible right now. Unless there is something else scrawl absolutely wants to be changed, I suggest to just go ahead with the changes we made and see how it works out.

What are the changes we made though? I think that's the point of confusion. And I totally get not retroactively changing all the issues when they're all going to get changed again anyway, but for new issues what should we do?

That's probably close enough - though it does raise the question whether priority, category and severity should be left in their current intermediate status, or should be moved either into "submitter encouraged to fill them in" or "submitter locked out".