After additional investigation, it seems like the id attribute has more consistent implementation (at least in Beaker browser, which I think is Chrome-based). This comes after playing with this example:
<label for="beans">How many beans can you eat?</label><br>
<progress id="beancount" max="500" value="250">
<!-- <output id="beancount">250</output>/500<br> -->
</progress><br>
<input oninput="beancount.value=parseInt(beans.value)" type="range" name="beans" id="beans" min="0" max="500" step="10">
The id attribute works for <progress> but the name attribute does not. The id attribute works for <output> as well (instead of using the name attribute as previously) but unfortunately leaving <output> as a fallback for <progress> causes <progress> not to update. That’s why I’ve got the <output> line commented out.
Given that name is obsolete for use defining anchors, and <progress> is a newly-defined element, I would have been surprised if name worked there. It shouldn’t. Some browsers may support it but that’s not standard behavior (or at best is in the “legacy behavior you can support if you insist” category).
It is also worth noting that the only reason we still include the name attribute at all, is because this is the name given to the data point when you submit the form to the server and the data is sent across. It needs an identifying name so that you can grab it and put it in the database or whatever on the other side.
I am not 100% sure, but I don’t think it even submits the data if you don’t give it a name.