Hello @jacobtylerwalls!
What’s the reason to want to avoid creating a new set so bad? These objects should normally have only a few members as most models usually don’t have more than 20 fields and usually when you use update_fields you want to target a small subset of them a so a new set should have a low memory foot print.
From some local testing it takes about as much time to perform isinstance(update_fields_list, set) than to systematically do set(update_fields) and it’s also usually bad practice to alter a mutable argument passed by reference as that can unintended side effects. On CPython 3.10.x it appears to be faster with update_fields: set than other iterables so it seems like a faster path is taken already for creating shallow copies.
What if the save caller was planing to use update_fields: set for other purpose after calling save? A similar issue was caught recently with refresh_from_db.
With JSONField maturing in core without proper update_fields={'json_field__key'} support and a long standing desire to entirely replace auto_now and friends with fields that use default but have a way to opt-in into update_fields injection I think we’ll want to revisit how this feature is implemented in the future.
I’m not convinced that a core function is warranted here. I think it might be better to invest efforts in coming up with a generic solution to the problem of derived / generated fields and their interactions with update_fields.