Was this convention communicated when it was decided on? I can't find anything in my email (which doesn't mean it's not there). I started doing (b) because it looked like what other people were doing (including Brad :).
In the process of doing (b) I found that I strongly dislike it. It interacts very poorly with Github's auto-closer, which closes the issue when it gets committed to master (which requires manual re-opening, which often doesn't happen) and does not re-close the issue when it gets committed to the release branch (which requires manually re-closing the issue, which often doesn't happen). This means you can't get any information whatsoever about the state of things by looking at issue search pages.
(a) seems fine. It requires a little more work, both to write the new issue and during cherry-picking, and requires that you remember to create the new issue once the CL is ready. But it's dramatically better information-wise.
Did we consider using Github labels for this? There seem to be three states to issues that are candidates for the release branch: "not fixed", "fixed on master, not cherry-picked", "fixed on master and cherry-picked to release". Could we have just one issue, which is milestoned for the release, let "closed" mean "fixed on master, not cherry-picked" (which the auto-closer will do for us), and use a label to mark "fixed on master and cherry-picked"? A bot could even apply this label when it sees the cherry-pick, though doing it by hand would be easy, too. This requires no more work than (b), keeps state transitions monotonic, and clearly shows the full state of the world directly in the search results.