@wilsonge here is the full version of this idea:

// An object to hold UI related methods and events
Joomla = {};
Joomla.UI = {
	methods: {
		Modal: {
			close: function(element) {
				for (var p in Joomla.UI) {
					if (p !== 'methods' && p !== 'events') {
						if (Joomla['UI'][p]['Modal'] && Joomla['UI'][p]['Modal']['close']) {
							Joomla['UI'][p]['Modal']['close'](element ? element : null);
						}
					}
				}
			},
			open: {
				// Propagate the call to all frameworks
				// Framework initiator has the responsibility to
				// Either respond and execute or do nothing
			}
		}
	},
	events: {
		Modal: {
			onShow: {

			}
		}
	}
};
Joomla.UI.Joomla = {
	Modal: {
		close: function(element) {
			// If there is a modal with the given element close it,
			// else check if ther is a BS modal open and then close that
			// else just do nothing
			console.log('I will close the Joomla custom elements modal');
			return false;
		}
	}
};

Joomla.UI.BS = {
	Modal: {
		close: function(element) {
			console.log('I will close the BS modal');
			return false;
		}
	}
};

Joomla.UI.Foundation = {
	Modal: {
		close: function(element) {
			console.log('I will close the Foundation modal');
			return false;
		}
	}
};

Copy paste it in your browsers terminal press return and then enter Joomla.UI.methods.Modal.close()

Pretty straight forward (especially if Joomla cover Bootstrap and custom Elements)

What's Joomla.UI.Joomla for - it's not quite obvious

Dummy name (maybe for custom elements?)

Think Joomla, BS and Foundation as different concurrent running frameworks

I'm unsure then. I'm very unsure about making it 'easy' for people to support different frontend frameworks at the same time. It's something that's just asking for a disaster to happen. If we wanted to support that your structure makes sense. But we actively do not want to support that.

The point is not to have multiple concurrently running frameworks! That would be plain stupid, and anyone doing that should be banned from the internet :) .
Essentially this is about the decoupling from any framework and defining an API that will not change in the next version of bootstrap or whatever the future holds for the project. Maybe I gave you the worst example ever, here :(

hm, I am more and more thinking that the system modals (select file, select article, select user etc etc) should be a standalone script, without relating to an any framework, then we will not have such problem at all. As it was in the past.

Really it just make a problems, where they should not be
In my extensions I use http://dimsemenov.com/plugins/magnific-popup/ but in the wild should be something without jQuery for J4.0 for sure

@Fedik my idea was to use custom elements for whatever Joomla is using (tabs, modals, accordion, dropdown), and here is my first attempt: https://dgt41.github.io/bs4-custom-elements/
Good thing with this approach is that we go framework free...

@dgt41 maybe I something not understood,
Let's say, Joomla! will have <bs4-modal>blablabl</bs4-modal>
and I am doing the template on my site, based on Foundation. what should I do?
how I should use <bs4-modal></bs4-modal>?

<bs4-modal></bs4-modal> is a custom element that comes with predefined methods, events, attributes and of course it's own styles. So by including (e.g. $doc->addCustomElement('bs4-modal')) you are already CSS framework free and javascript framework free! This is how a div or an input is build inside any browser so instead of cannibalising some divs to make a modal we are defining it. That's the way to go for UI, IMHO

thanks for explanation, this is still confusing ?

Maybe looking at some other custom elements is more explanatory, http://strand.mediamath.com/strand-dialog.html

But we actively do not want to support that

@wilsonge you realise that the code I used in the comments Joomla.UI.methods.Modal.close() is not the same as the code used in the PR Joomla.UI.Modal.close(), so let me know how you want to resolve this.

@Fedik you mention that you have an idea for the modal close mess, can you give us an example?

@dgt41 yes, I want to suggest another idea, based on custom events.
The key is that "script which open the modal should close it, by himself, and do not wait when someone will do it"

As I have mentioned in #16016, the custom events can be used to send a "data" from script to script. So we can use it for the modal, to send data from the child window to the parent.

Pseudo code, for select article modal:

// field-modal js
(function(){

 // Open popup. UPD: programmaticaly
 openModal(); 
 // Wait when user do the chose
 iframe.window.addEventListener('joomla:articleSelected', function(event) {
   var artIcleId = event.details.id,
         artTitle   = event.details.title;

    // Close popup window
   closeModal();
 });

})();

<!--  Article list -->
<a href="#" onclick="Joomla.Event.dispatch('joomla:articleSelected', {id: 100, title: 'Free beer!'})">
  Select This article</a>

So, in final the "Article list" do not care who open the window, it just dispatch joomla:articleSelected (or something) when user made chose, and the field-modal catch it and close the window itself.

@Fedik the modal can be either bootstrap or tinymce, how are we dealing with that case?

@dgt41 ah, I forgot that the bootstrap modal opens "magicaly" ?
I think that for complex cases we should open them "programmaticaly" only,
see "openModal()" in my pseudo code? ?

then you do not need to do stuff like:

window.parent.Joomla.editors.instances[editor].replaceSelection(tag);
window.parent.Joomla.UI.Modal.close();

which is "not nice" to be honest ?

and bonus, you do no need to know the editor id! ?

Same view is used in:
xtd button,
tinyMCE button,
admin com_menu (select article button)

If all these cases will work with the proposed code (event driven) let's do that then

Too many things in one PR, will split this to something easier to test/review