What is the purpose of additional variable that is essentially an inversion of self.issimple?

which name is more descriptive without extra long documentation: issimple or is_smart_ptr?

Actually both of them sound weird, because they are wrapping strategies (same for ismap), but treated as class properties.
The main idea behind a comment that the only one of them should stay.

I have prepared minimal set of changes in gen2.py:

4.x...alalek:opencv:pr22934_minimal

If it is fine, then I could replace the first commit to avoid question with code refactoring.
@VadimLevin please take a look

LGTM, but can you elaborate this change?

arg_type_info = simple_argtype_mapping.get(tp, ArgTypeInfo(tp, FormatStrings.object, defval0, True)) # Removed
if tp in simple_argtype_mapping:
    arg_type_info = simple_argtype_mapping[tp]
else:
    if tp in all_classes:
        tp_classinfo = all_classes[tp]
        cname_of_value = tp_classinfo.cname if tp_classinfo.issimple else "Ptr<{}>".format(tp_classinfo.cname)
        arg_type_info = ArgTypeInfo(cname_of_value, FormatStrings.object, defval0, True)
        code_arg_usage = code_arg_usage if tp_classinfo.issimple else '*' + code_arg_usage
    else:
        arg_type_info = ArgTypeInfo(tp, FormatStrings.object, defval0, True)

tp already should be a cname or Ptr<cname> without extra tweaks.
If it is related to UMat export strategy change, it is already covered by simple_argtype_mapping.get with default.

There is a mess in generator:

• tp - is an argument type
  • (FileStorage& fs): FileStorage
  • (const Ptr<FileStorage>& fs): Ptr<FileStorage>
• it may contradict with python's storage type (which doesn't depend on argument's type):
  • Ptr<FileStorage> always (non "simple" type)
  • arguments wrapper doesn't use this information at all
• currently tp is used as local variable which is not always correct. Switch on python storage type is needed (it is a smart pointer or direct type).
• finally, pyopencv_to() usage is corrupted
  • because pyopencv_to is generated for storage type only

CV_WRAP's change const Ptr<FileStorage>& fs -> FileStorage& fs raises this error without patch:

modules/python/src2/cv2.cpp: In instantiation of ‘bool pyopencv_to(PyObject*, T&, const ArgInfo&) [with T = cv::FileStorage; PyObject = _object]’:
modules/python/src2/cv2.cpp:76:27:   required from ‘bool pyopencv_to_safe(PyObject*, _Tp&, const ArgInfo&) [with _Tp = cv::FileStorage; PyObject = _object]’
build/opencv/modules/python_bindings_generator/pyopencv_generated_types_content.h:1041:25:   required from here
python/src2/cv2.cpp:91:94: error: ‘to’ is not a member of ‘PyOpenCV_Converter<cv::FileStorage, void>’
   91 | bool pyopencv_to(PyObject* obj, T& p, const ArgInfo& info) { return PyOpenCV_Converter<T>::to(obj, p, info); }

How it should be fixed:

• generator should know both types (including missing knowledge about smart_ptr "modifier")
• generator should align usage of them

BTW, UMat is some kind of smart pointer, so no need to wrap it into smart pointer again. Existed wrapping is heavy hijacked (see CV_PY_TO_CLASS definition and CV_PY_TO_CLASS(UMat) usage). Fix of 2 level smart ptr wrapping of UMat is not in scope of this PR, so there is a hack with "recovering" through simple_argtype_mapping item.

What is the purpose of additional variable that is essentially an inversion of self.issimple?

There is #19156 on 5.x branch, so .is_smart_ptr approach need to restored.