I've followed the entire conversation and understand what you want but I don't think you'll get this in the way you want. The problem is that game UI uses some rendering technique like OpenGL/Vulkan or DirectX. It is an optimized mesh which is put into the VRAM of the graphics rendering unit and rebuilding the mesh is a quiet heavy task which needs to be done as fast as possible to not cause frame hickups. UI is also drawn on every frame but could be affected by shaders.

On the other hand there is GUI, this is handled by the OS, it manages windows and how they need to be drawn. Every window has a pixel buffer the OS is redrawing on demand. Then there are controls, which are managed in a parent-child hirachy and need to be clipped and merged together into the backbuffer. The window e.g. a control is only redrawn when something in the clipping area changes. This means that you can move the window around without the need to spend time into drawing the buffer again but the window management systems performs a little composition. This is why you won't find a windowing system for games.

Another feature you shouldn't forget about is Drag n Drop and Clipboard. This are features highly involving the underlaying OS but they're important for the user experience. So going cross-platform will at least involve a lot of work as you have to make use of the WINAPI and X11 and whatever platform you also want to support and then you slide into studying those APIs all day in order to get something done. We're currently on the same track as for our opinion, the existing windowing frameworks don't fit our needs of simplicity and non-monolithic software solutions, so we started to write our own API. But it was already a lot of work to just get some window to appear and handle the usual stuff.

On the choice of language, your arguments are to neglect as it seems you don't have much knowledge of the alternatives. C/C++ is standard in game development. The difference between C and C++ is the OOP aspect but you're not forced to use classes rather than free functions. I'm using both, whatever fits the situation in our game engine, we have both classes and free functions.

C# on the other hand is also a standard in game development. Unity is utilizing C# as development language, Unreal and our team is using it as tooling language as well. It allows for cross-language interopt calls and you could even write your game editor in C# without any hussle. C# is a runtime language, so you need a runtime installed on your computer and assemblies are written in op-codes which need to be interpreted by the runtime. C# is however different in the fact that their op-codes (IL for intermediate language) are JIT (just-in-time) compiled into platform assembly. This speeds execution up A LOT!

Whatever you'll do, I assume you will either have to spend a lot of time or money into your project. I know very little games which offer an in-game editor, your best bet could be to look at the Unity source code which is partially available on GitHub (and written in C# ?)

If you want to develope for multiple target platforms, some kind of build scipt system like MAKE could be useful. Cross-compilation is somehow more difficult to setup but also possible. Or you write your own solution, a couple of command-line scripts for example

C-Research said:
I want to spend my main focus on C for a year or two so after a few years with the various levels of framework, I will know when to use C, C++, and where the boundary exactly should be in certain cases for a scripting language

However you like to go is up to you but let me tell you that C++ is just C with OOP. Learning C and then trying to find “the borders between C and C++” is nonsense.

You shouldn't forget that modern SDKs you need (like the Android NDK) are written in C++

C-Research said:
My intended market segments of end users are mostly Windows and Mac, but I develop on Linux and want to support the Linux game community, too. Android is a secondary but serious consideration.

That's a straight goal, however you need a MAC to build Objective C, which is how Apple systems work. I don't know about Unreal but at least Unity only creates an Objective C project instead of a compiled executable for Apple target platforms. Supporting Apple in my opinion is not worth it as the Apple gaming community is quiet small. If you want to target iOS instead, then this could be a goal but you anyways need a MAC and an Apple developer account or else nobody will be able to get your game from App Store.

We're focussing on Windows/Linux/Android and probably the major consoles from Sony and Nintendo, deciding against Apple very early in the design process. Android is a logical choice if you target Linux/Unix as Android is based on the Unix Kernel and you need just little effort to port C++ to it. A simple Java class that bootstraps into your C++ code is enougth.

C-Research said:
How about CMake? Is it too difficult to develop with CMake in targeting Win/Mac/Linux and reach out to Android, too?

I assume every make-ish build tool could solve that task for you. I personally don't like build script environments as they're very affected by small issues like whitespace in paths and this will lead to compilation errors very fast. Especially very big scripts could then become a debugging nightmare.

That's why I started a configurationless build tool 2 years ago, inspired by Unreal Build Tool and an article I found on Gamasutra about a Python based build system. Our solution is absolutely modular and performs data driven building by just providing a (bunch of) path(s), some command line arguments what it should do and let the tool determine everything else for you. It has become quiet handy and speeds my daily work up a lot. But it is written in C# ?

C-Research said:
By the way, I like using Terminal and have built a few things with Nano / Meson / Ninja, though some things are much more productive in an IDE for me. It seems to be a case by case basis

True. It however depends of the language, in C# it might look like you might not come around Visual Studio or at least MSBuild at some point but that isn't true, at least if you spend some effort and/or have the right tools on hand. Another benefit of our custom solution, it allows to just write C# in text editor and have the tool manage everything else from target framework up to dependency management.

C-Research said:
I prefer to use Linux, but I feel it is inevitable that some things will just have to be developed on Windows 10

At least when it comes to very OS specific stuff like using a window management system I guess

C-Research said:
Future team developers (after I form a group)

We're btw. always looking for new members so even if your goals and ours might not be the same in the end, it can be useful to walk along the way together for certain amount of time ?

Just PM me or look into our Hobby Project post if you want to know more

Shaarigan said:
then this could be a goal but you anyways need a MAC and an Apple developer account or else nobody will be able to get your game from App Store.

When i made a iPhone game, i had a MacMini in the basement but did not want to use it.
So i installed MacOS on VirtualBox with Windows host, and this was enough to run XCode and do the AppStore upload / approval process.
Just saying - it's probably not legal, but it worked at least 8 years ago ; )

JoeJ said:
it's probably not legal, but it worked at least 8 years ago

Yeah, I know you can use a VM but it is the “not legal” part from the Apple EULA which should be warned for. I've worked on some Apple projects as well, especially my previous employer who's game design software was targeting Apple as well (because it seems most screen writers are Apple fanboys) so I know how “good” their hardware is ?

Haha, coming from DTP artwork and music industry, i know these creatives / Apple fanboys too. They were ofc. resistant to switch to another, cheaper platform, which was ‘more complicated to use, and buggy’. Thus i also have some experience with setting up Hackintoshs to find a cost effective middle ground. Looking back now i'd say better buy real Apple HW to avoid the frustration of maintaining Hackintoshs, as updates become a pain. (even with legal issues aside)

Shaarigan said:
so I know how “good” their hardware is

How times change.
Actually i could get a M1 laptop at MSRP, which is not even more expensive than comparable power hungry PC toasters. Their HW seems some years ahead, currently.
Though, their walled garden, abandoning crossplatform APIs, etc… It's still not really an attractive platform for games, imo. Too bad.
But if i worked on a game i would still release on Mac too. The guys of Frictional Games said they would not have survived, if they wouldn't had supported Mac and Linux with their first game.

@c-research Coming back to topic, probably the discussion derailed to a ‘C++ guys convincing C guy to adopt’ too much, which is to expect ; )

It seems your main concern is GUI, and i just saw raylib has quite a lot of stuff, including tools to design it. Maybe it lacks customization and automatic scaling to support different screen resolutions, but idk.
At least it supports icons, so i guess it can also include colored images in it's GUI. Font support seems pretty complete.
To have something like an inventory showing items in 3D, you could render the items to a texture, and display using the icon functionality eventually.

So what are the things you miss from the given functionality?

Edit: Just found EAs port of WebKit, which is open source but not sure about license: https://gpl.ea.com/eawebkit.html
I'd

C-Research said:

My intended market segments of end users are mostly Windows and Mac, but I develop on Linux and want to support the Linux game community, too. Android is a secondary but serious consideration.

How about CMake? Is it too difficult to develop with CMake in targeting Win/Mac/Linux and reach out to Android, too?

In that case you will be far better off using an engine like Unreal or Unity. The platforms are supported automatically.

Or libraries like cocos2d-x. You will write more code but have a bit more control.

Without them, you will be writing all the abstraction layers for all the systems. It can be done with a group of experts across several years, but it is time spent not making games. Engine companies do it, but they aren't making games in the process, they are supporting games. The UI problem will be the least of your concerns.

CMake will help generate build scripts. It won't help create cross-platform libraries for graphics, audio, disk, network, or other systems.

Whatever route you take, you will need the UI solution to be deeply integrated into the rendering system. The design needs to match current hardware patterns for good performance, and will need to be adjusted on each platform for OS quirks.