To test if the check if mtime_orig != mtime_new: is indeed the problem, I made an operator (simplified version of the original addon_enable(): developer.blender.org/diffusion/B/browse/master/release/scripts/modules/addon_utils.py$327) with that removed:

class OBJECT_OT_reload_module(bpy.types.Operator):
    bl_idname = "object.reload_module"
    bl_label = "Reload specified module"
    bl_options = {'REGISTER'}

    def execute(self, context):
        print("Hello")

        import importlib
        import sys

        module_name = "your_module"
        mod = sys.modules.get(module_name)
        mod.__addon_enabled__ = False
        try:
            importlib.reload(mod)
        except Exception as ex:
            # handle_error(ex)
            print(f"Failed: {ex}")
            del sys.modules[module_name]
            return None

        mod.register()
        # * OK loaded successfully! *
        mod.__addon_enabled__ = True

        return {'FINISHED'}

and indeed, the add-on properly reloads now.
So I would suggest solution 2 in the main post.

Thank you @Sybren A. Stüvel (sybren) , bpy.ops.script.reload() indeed reloads all add-ons. I had if "bpy" in locals(): check to reload add-ons, but that wasn't triggered by my code, because __init__.py didn't change.

While luckily indeed a smaller issue than I assumed, I think it's not a solved one.

1. When asked at blender.chat Python API channel: https://blender.chat/channel/python?msg=fGEyJtjNZqfpApxQ5 , none of the multiple people who responded pointed me to bpy.ops.script.reload() instead of bpy.ops.preferences.addon_enable(module='your_module') I would assume the most knowledgeable Python programmers are active here, and therefore it seems bpy.ops.script.reload() is not common knowledge. This is more a documentation issue, so I created an issue about this here: https://developer.blender.org/T67387
2. bpy.ops.script.reload() reloads ALL add-ons. If one of these add-ons is producing a error / warning, it will pollute the output/logs for the add-on you're actually try to develop. Also, if (multiple) non-relevant add-on(s) are slow at initializing, it will slow down the development process. Possible solutions I could think of:
   1. Allow for an argument to bpy.ops.script.reload(module_name=None), and only reload all when either None or no argument is passed.
   2. Make bpy.ops.preferences.addon_enable(module='your_module') intended for reloading specific add-ons by remove / extend the check if only __init__.py file changed.

For development, you can:

import importlib
importlib.reload(your_addon_name)

Checking the date on the init file isn't meant to be a comprehensive check of the entire package.

In T66924#729370, @Iemand Iets (NumesSanguis) wrote:

I would assume the most knowledgeable Python programmers are active here

Not all of them, and not all the time. Just search the Python API documentation for "reload script" and you'll find the bpy.ops.script.reload() operator. Granted, it's not documented very well.

if (multiple) non-relevant add-on(s) are slow at initializing, it will slow down the development process.

Well, if you keep multiple non-relevant add-ons enabled while you're developing, I don't think this is an issue with reloading. I think it's an issue between keyboard & chair.

In T66924#729380, @Campbell Barton (campbellbarton) wrote:

For development, you can:

import importlib
importlib.reload(your_addon_name)

You could even add this code to an operator in your add-on and bind it to a menu item or button, then it's literally a one-click reload for only your add-on.

I have created a workaround to this problem.
Example __init__.py:

import importlib, sys # required

# reloads class' parent module and returns updated class
def reload_class(c):
	mod = sys.modules.get(c.__module__)
	importlib.reload(mod)
	return mod.__dict__[c.__name__]

# imports to be updated
from . somefile import someclass
from . import somemodule

someclass = reload_class(someclass) # reload imported class
importlib.reload(somemodule) # reload imported module

...

someclass and somemodule will stay up-to-date when reloading addon with bpy.ops.preferences.addon_enable() and with bpy.ops.script.reload().

Don't use the from X import Y syntax to import individual classes, that'll make reloading more cumbersome (as you've seen). If you just import (sub)modules you avoid the need for that reload_class() function.

In T66924#730083, @Sybren A. Stüvel (sybren) wrote:

In T66924#729370, @Iemand Iets (NumesSanguis) wrote:

I would assume the most knowledgeable Python programmers are active here

Not all of them, and not all the time. Just search the Python API documentation for "reload script" and you'll find the bpy.ops.script.reload() operator. Granted, it's not documented very well.

That's good advice. I've gotten so used to just Googling things and usually finding the answer on stackoverflow, I forgot about direct searching.
For some reason Google doesn't index the Blender documentation, which would probably trouble more newcomers to Blender.

if (multiple) non-relevant add-on(s) are slow at initializing, it will slow down the development process.

Well, if you keep multiple non-relevant add-ons enabled while you're developing, I don't think this is an issue with reloading. I think it's an issue between keyboard & chair.

While in most case you'd be right, there are people who develop add-ons, that rely on / add functionality to add-ons of others. It is not always possible to merge this into 2 add-ons.
You could say, you could help speed-up that add-on, but some add-on creators are satisfied with their solution of whatever reason they have to not accept your contribution.
Also, it's possible that the add-on you rely on is good, but only requires a long initialization time (e.g. setup TCP connections to programs outside Blender, not so weird if you want to visualize data from a Robot).

The situation at the moment is:

• A function that can reload single add-ons, you're not supposed to use (bpy.ops.preferences.addon_enable(module='your_module'))
• A function that can only reload all add-ons (bpy.ops.script.reload())

Is it a huge problem? Not really. However, to me it feels like poor design that you can't just reload 1 add-on. Even if in most cases reloading all add-ons won't be much of a slowdown.
Would you say it makes sense if there is a function that can reload a (list of) specific add-ons? Given it's not too much effort to implement.

p.s. Could someone point me to the reload script?

• There is no link from the documentation to the code.
• Searching importlib doesn't find me anything on https://developer.blender.org/diffusion/B/browse/master/
• Googling (Startpage) site:https://developer.blender.org/ importlib doesn't show up anything either.

p.p.s
Asked for referencing the code by making the function names on the documentation page clickable: https://developer.blender.org/T67674

In T66924#729380, @Campbell Barton (campbellbarton) wrote:

For development, you can:

import importlib
importlib.reload(your_addon_name)

You could even add this code to an operator in your add-on and bind it to a menu item or button, then it's literally a one-click reload for only your add-on.

Yeah, I did this. Is slightly less smooth if you're bugs are in the registering of the modules, which breaks the unloading, although that could have been because of me using addon_enable :')

Recently , I notice that use reload() will destory the socket connection(when it became complex) on win. (win 10054 error)