In my mind, moving a PR to draft and then back to published is equivalent to submitting a new PR (under the unfounded assumption that you move to draft only if you want to significantly rework the PR).
I can see how other interpretations also make sense, and I don't have a strong opinion myself (especially not being a core dev :) ) and happy to look into making changes in the draft workflow - but I'd like to have someone authoritative (that someone can be you ofcourse) providing guidance about what should be the desired workflow first!

under the unfounded assumption that you move to draft only if you want to significantly rework the PR

For me, that's an incorrect assumption ;)

It's not unusual for me to do testing locally, think I've got a strong PR, file it on GitHub... then get cold feet, so I'll put it back into draft while I do some more testing locally, just in case somebody else merges it while I'm doing more testing. But then my local testing proves my fears were incorrect, so I move it out of draft again without having changed much at all!

In general, I agree with Itamar. But if the commit hasn't changed since it was approved, and if it's easy to check that, I think would be nice to go straight back to "awaiting merge"

But if the commit hasn't changed since it was approved, and if it's easy to check that

I'm sure it could be done with a bunch of additional labels. I don't know if this would be considered easy (or desirable) :)

More labels sounds like a bad idea!

I found the sequence in python/cpython#104559 surprising, but it sounds like I might be in the minority (and it's not a huge issue, anyway), so better to do nothing here than add loads more complexity, I think :)

Let's not add more labels. In my mind if a PR already has awaiting merge label, we should not move it back to draft. You could add the "do not merge" label if you still need to work on it more. So I think the behavior that's currently implemented is correct.