seems that merged patch by @Damien Picard (pioverfour) Rigify: store advanced options in armature instead of window manager fixes it for 2.82.
still there are some minor issues relative to naming and python ui.

• the patch removes the '_rig' suffix from rig name, still this name is retained for the python ui script: Creating a rig with no name should roll back to default 'rig' as rig name and should logically output 'rig_ui.py'. If advanced option is set to "new" and a new name is set (for example 'new') the python ui script should named accordingly (new_ui) but will instead still append '_rig_ui' to the name. The python ui script and the rig should have consistent names.

• If options is set to new and no name is set, generate will roll back to use 'rig' as name. if another rig is present in the scene a new 'rig.001' is created but the associated ui will be 'rig_ui.py.001' instead of 'rig.001_ui.py'

This bug was introduced by rBA3423174b37a0.
@Alexander Gavrilov (angavrilov) It seems that a 2.81a release is planned, should the fix be backported before then? @Nathan Letwory (jesterking) said “If we do we may wait some extra days to see if any other pressing issue is found”, but I don’t know if this qualifies as a pressing issue.

@Ivan Cappiello (icappiello) You are right about the Python script’s name, for it to be registrable, it must end with .py. Perhaps it should just use the generated rig’s name, something like:

diff --git a/rigify/rig_ui_template.py b/rigify/rig_ui_template.py
index bb5a9cbd..e9168483 100644
--- a/rigify/rig_ui_template.py
+++ b/rigify/rig_ui_template.py
@@ -1163,9 +1163,13 @@ class ScriptGenerator(base_generate.GeneratorPlugin):
 
         # Generate the UI script
         if metarig.data.rigify_rig_basename:
-            rig_ui_name = metarig.data.rigify_rig_basename + '_rig_ui.py'
+            rig_ui_name = self.generator.obj.name + '_rig_ui.py'
         else:
             rig_ui_name = 'rig_ui.py'
+            i = 1
+            while rig_ui_name in bpy.data.texts:
+                rig_ui_name = 'rig_ui.%03i.py' % i
+                i += 1
 
         script = None

About the _rig_ui vs _ui issue, it doesn’t bother me too much, I feel _rig_ui is more descriptive.

In T71678#818028, @Damien Picard (pioverfour) wrote:

This bug was introduced by rBA3423174b37a0.
@Alexander Gavrilov (angavrilov) It seems that a 2.81a release is planned, should the fix be backported before then? @Nathan Letwory (jesterking) said “If we do we may wait some extra days to see if any other pressing issue is found”, but I don’t know if this qualifies as a pressing issue.

i already wrote @Brendon Murphy (meta-androcto) and this could eventually be included in 2.81a

In T71678#818028, @Damien Picard (pioverfour) wrote:

About the _rig_ui vs _ui issue, it doesn’t bother me too much, I feel _rig_ui is more descriptive.

i don't agree. If you remove the _rig suffix from generated rig name for a reason, the same reason applies to python ui script. Please make tools consistent. Either you remove _rig from both or you leave it both places.

This is a simple editing mistake that happened when splitting a huge function into class methods:

--- a/rigify/generate.py
+++ b/rigify/generate.py
@@ -114,7 +114,7 @@ class Generator(base_generate.BaseGenerator):
         self.widget_collection = ensure_widget_collection(context)
 
         # Remove wgts if force update is set
-        wgts_group_name = "WGTS_" + (self.rig_old_name or obj.name)
+        wgts_group_name = "WGTS_" + (self.rig_old_name or self.obj.name)
         if wgts_group_name in scene.objects and id_store.rigify_force_widget_update:
             bpy.ops.object.mode_set(mode='OBJECT')
             bpy.ops.object.select_all(action='DESELECT')

In T71678#818622, @Alexander Gavrilov (angavrilov) wrote:

This is a simple editing mistake that happened when splitting a huge function into class methods:

Hi, little nitpick, meant just as a friendly note:

1. Those are not class methods but instance methods (refer 'self', not 'cls'). Python has also class methods, but they seem to not be used there.

2. I think a Python Linter would catch such errors, kind of like a compiler, note that 'obj' is unknown there. Maybe helpful to use as a part of the Blender Python workflow somehow