X Windows can detach itself from the console display device and associated input devices allowing those devices to be used by another instance of X or the Linux kernel as virtual text consoles. what i want to know is what is the correct terminology for this that experts of X would know.

Not sure if it's correct but i would call it an X-Terminal. I used to be involved in repairing Sun Microsystems kit, we had quite a few X-Terminals whose only job was, as a client, to provide a display and keyboard/mouse input to the host server elsewhere. All the OS and data was on the server, on switch on the X-Server was uploaded with the necessary display terminal handling program. There used to be a program called SLXT (Looks like it may mean something different nowadays!) which allowed a Sun X-Terminal with a 50Mhz Sparc processor and at least 12Mb of RAM to run an X Server session from a Linux powered box.

My

Play Bonny!

X uses the client server model and has always been "detached" although for most users both run on the same physical device.

https://en.wikipedia.org/wiki/X_Window_System

It is the elegant and efficient system that Microsoft's "remote desktop" never could be.

I don't understand what do you mean by that.
X does not detach itself from the console it was started from. Instead, it redirects the events "arrived" on the given device to the appropriate window (depending on the focus to the terminal or browser or whatever). X will generate virtual terminals for terminal emulators and other apps and those apps will handle their virtual (or pseudo) terminals as their real tty. But at the end all the events are generated by the only mouse and keyboard and X will forward them to those virtual ttys.
This virtual device is called pts, pseudo terminal, that's why it is pts and not tty. see man pts.
But probably I misunderstood and you are looking for something else.

every response seems to be referring to a client or a virtual terminal which communicates with an X server over an octet stream connection using the X protocol. i am not referring to any client nor any virtual terminal. Linux is capable of hosting multiple instances of an X server. each will be associated with a different console virtual terminal allowing the user to switch which instance of X is being used at the computer's console. the user can do this by pressing (typically) Ctrl+Alt+Fn where n is the console virtual terminal to be operated by the user. when this switch takes place between X servers the current X server quits using the console (display, keyboard, mouse) and the next X server begins using that console.

my question was what term is used within X windows to refer to this kind of switching.

I do not know exactly it works but no different from switching between any virtual console. Most distributions create 6 virtual consoles F1-F6, the 1st X server is F7 and the second is F8 and so on but it is configurable. You can switch between any one when X is running using ctrl-alt F1-FX. If X is not running alt F1-6 is used.

That is still wrong. Actually using Ctrl-Alt-Fn (or Alt-Fn without X) you will be able to switch your consoles. You can use only one of them. X is initially attached to tty1 or tty2 or ttyN, and you will only see the one which is attached to the current console. Other ones will still work and would be able to handle keyboard and mouse events, but kernel always sends them to the active console which will forward them to the app running on that console (which is the X server itself).

To me the switching doesn't seem to exist within X Windows. See man chvt.

X still has to handle the switch. both Xs need to when switching from one X to another one. suppose you switch from X on F7 to X on F8. X on F7 must release resources it (video driver) is using on the video hardware and know not to write the video RAM. X on F8 now takes over and updates the video RAM. it can even be running a different video mode (i used to do that with 3 modes, many years ago). i even tried 4K video that way in 2019.

you can have quite a mess if multiple Xs are updating the display at the same time.

it is a switch between Xs but they must cooperate for it to work. also, X gets the keypress events for Ctrl + Alt + F8 so it has to get things started. i don't know all the nitty gritty details of the switch.

now days lightdm manages this on Xubuntu. i have run as many as 22 instances of X at once. at this moment i have 16 (:0 .. :15) running and am using :2. i use dm-tool to do the switching via shortcut hotkeys.

i think we are just using different terms for the same things.

No. X is attached to a terminal like tty1 or similar. It cannot be changed at all, this connection is created when X started and will remain as long as the server process is running. There is no any way to alter it.
When you switch to another terminal (to tty2) the kernel will do that and that means the real keyboard and mouse events will be sent to tty2 (always to the active tty) and also the "content" of tty2 will be displayed. The X on tty1 is still running, accepts events and works as usual, just you can't see that.
Again, the switch is made by the kernel and not by X. The keyboard events (Ctrl-Alt-Fn) are captured and handled by the kernel and will not be sent to the X server (any of them). Theoretically you can use any number of X servers and they do not cooperate, do not communicate with each other (and actually they do not care about that at all).

There is a probably interesting case when you start an X server from a terminal emulator within an X session and not from a tty.

1. tty1 is not a terminal, it is a virtual terminal. see man chvt. what do you mean by the word "attached"? we apparently disagree on terminology. do you have supporting evidence for your usage?

2. "... just you can't see that." why not? it is because that X server is not updating the hardware video RAM. if both X servers were doing that at the same time, you would be seeing a mess on your real screen.

3. "Again, the switch is made by the kernel and not by X." the truth is that both are involved. X has direct access to the real hardware video chip as granted by the kernel. each unswitched X server knows it is unswitched and pauses such access. if one of them does try to do such an update the kernel may well reject the operation of that syscall; but this is not literally necessary. maybe you mean that the kernel carries out the switching protocol. but both X servers are involved in that.

4. "There is a probably interesting case when you start an X server from a terminal emulator within an X session and not from a tty." have you tried that to see what happens? can you predict what will happen? i can tell you that it will fail and give you an error message (via stderr over the pseudo-terminal being used by that instance of terminal emulator). i doubt it will be much interesting. you could have more fun starting X VNC (see man xvnc when you have it installed).

And? Obviously tty1, tty2 ... are all virtual terminals. From this point of view it is completely irrelevant.
Attached means attached. X server itself is attached/connected to that tty. You do not need to agree with anything, just check the X server process which is running like this:Because you can always have only one active [virtual] terminal.
No. Can you prove it? I don't think so.
You can have a few virtual terminals and you can always select which one do you want to use, regardless of the programs running on that terminal. (yes, X is just a process as any other one). All these terminals have a virtual display and virtual input, but only the active one is connected to the real hardware (by the kernel).
You can imagine something like this: there is a display buffer (attached to the tty) and X will write into it.
No process can have direct access to any part of the real hardware, but the driver. Only the driver can (and allowed to) communicate with the device.
No, you need to prove that too. X has no any idea about that state, there is no such thing as switched/unswitched. X server itself is a client-server pair of applications. Ok, it is not really relevant, and I don't want to go into details, but it is much more complex than you think. X client and server side can run on different hosts. Also you can have several hundreds of X running on the same host which are all active and "switched", just their "display" sides running on different hosts or in different VNC like sessions or .... Also we can have X servers running completely without any real device (in VMs for example). X can run on hosts without video card. (Not that important, but: have you heard about citrix? with citrix [for example] you can detach X client and server side from each other and reconnect later)
How should those X servers handle all these different situations?

> Because you can always have only one active [virtual] terminal.

but you can have more than one active process that has device driver access.

> No, you need to prove that too. X has no any idea about that state, there is no such thing as switched/unswitched.

X does many things different when unswitched. it knows. and these days it can affect, or be passed on to, clients. Firefox is one example where i have seen changed behavior as a result of its X server being unswitched.

from your ps example, it appears that you (like most people) regularly use only one instance of X. thus, you would have little experience, if any, of X in an unswitched state.

yeah, they have been running since yesterday, when i last rebooted after an upgrade,

and yes one (figurative you) can have many instances of X running with working displays that are not in an unswitched state.

> How should those X servers handle all these different situations?

i have tried X over VNC but decided not to use it because of issues with the client i was using (ease of switching, for one). so i never established a concern how X servers handle all these different situations. thus, i have no answer for that question. my concern is for the X servers associated with (attached to) virtual terminals in an unswitched state.

FYI, i can switch to my "forums" user (where i am right now) with alt+f when it is already logged in.