They share some similarities but the goal and target is different:
- the purpose of
untriagedis to indicate to other triagers that they should look at the issue and triage it, so that it doesn’t go unnoticed. - the purpose of
acknowledged(or the initially proposedaccepted) is to inform the author that their issue has been seen and/or accepted.
For example if I see an untriaged issue about asyncio and I can reproduce the behavior on 3.10/main, I might add the type-bug, stdlib, expert-asyncio, 3.10, 3.11 labels, and remove the untriaged label. This will notify the asyncio expert and they (hopefully) will take it from there, either by fixing the issue or by closing it if it turns out the behavior is expected/intentional.
acknowledged/accepted might also create expectations in the author, and has the disadvantage that most open issues will end up with an extra label. Searching for -label:acknowledge might also bring up old/triaged issues that are awaiting for more information, an expert opinion, or are still being discussed, making it more difficult to find untriaged issues.
This idea of new/untriaged was initially proposed in Map bpo issue metadata to GitHub fields/labels · Issue #5 · psf/gh-migration · GitHub (as an awaiting triaging stage), and briefly in GitHub Issues Migration: label mapping - #16 by blink1073 (as needs triage label), but it didn’t get much traction. I brought it up again because templates now add some labels, making it more difficult to notice untriaged issues, however I’m not sure how many issues actually go unnoticed.
As @storchaka said, it might be enough to use the new proposed weekly report (bpo-to-github-migration replace roundup summary script by Harry-Lees · Pull Request #91738 · python/cpython · GitHub) and include a list of new issues with 0 comments (or 0 comments from triagers/core-devs).