In that thread, call NPPM_DMMREGASDCKDLG, MODELESSDIALOGADD and NPPM_DMMSHOW for that modeless dialog.
After I do that, Notepad++ seems to hang :(
Do I understand correctly that a docked dialog must not be created and registered from within another thread?

Well, yes, I think it was not a good idea to create it in another thread.
Once I move the dialog creation & registering as a docked dialog to the main thread, everything works OK.
Though, the question remains.
Why doing it in another thread causes Notepad++ to hang?

Though there’s another thing I don’t understand, this time in Notepad++. Why a docked dialog becomes visible immediately after NPPM_DMMREGASDCKDLG and MODELESSDIALOGADD? I mean, logically MODELESSDIALOGADD means “add a dialog” - correct? - so a dialog should not be shown before NPPM_DMMSHOW is sent explicitly!

If there was isVisible=“yes” in the “config.xml”, there would be an additional explicit call of the function which functionId was specified as the dockData.dlgID. But in my case isVisible=“no”, there was no explicit call of the plugin’s function - but the docked window became visible…

This would lead to the assumption that you might, maaayyyybeeee, checked
the false config.xml?? I know you are familiar with npps configuration
but, at least for me, sometimes you don’t see the wood for the trees.

Actually, if you look in Notepad++'s source where it uses these messages internally it normally calls:

NPPM_MODELESSDIALOG with MODELESSDIALOGADD

NPPM_MODELESSDIALOG with MODELESSDIALOGREMOVE

NPPM_DMMREGASDCKDLG

I think 1 and 2 are just a side effect of how the class inheritance works within Notepad++. So, it would appear that NPPM_MODELESSDIALOG may not even be needed for docked dialogs. I will look into this more if I get a chance.