If I wrote an installer for MS windows, it would still be MS windows after it was installed.
If I wrote an installer for Ubuntu, it would still be Ubuntu after it was installed.
How can a distro be distinguished? Actually it's a lot easier these days than it used to be.
First there is usually a file (sometimes two)
/etc/os-release or /etc/redhat-release usually most distro's have these two files even if they aren't redhat. These will usually tell you about the version of Linux you have.
The splash screens and logos, and backgrounds are a very small part of it. Sometimes the little icons in the GUI will be different depending on which distro you run, but those are just cosmetic things.
To find the real differences, you have to get into "the guts" a little bit.
Ubuntu and Mint are Debian based. They run dpkg and apt to install software.
They like their software packaged in a certain way. often I see someprogram.deb files.
CentOS, fedora, OracleLinux are Redhat based. They run rpm and dnf (used to be yum) to install software. They like their software packaged in an RPM file format. someprogram.rpm
The kernel version has a lot to do with it. Redhat 6 is still on kernel 2.6.x,
Redhat 7 is on kernel 3.10.x, Redhat 8 is on kernel 4.18.x. Fedora 32 is currently on 5.7.x.
The x at the end of those is really a number that may change every few weeks or months.
Then you have something called glibc. It is a C language library. Almost every thing on your computer
is compiled against a specific version of the glibc library. In fact the C compiler that compiles most of the Linux binaries uses the glibc library. There are different versions of the compiler. GCC 10.2 has been out for a while, but some distro's are still compiled GCC 9 or GCC 8.
The locations of the files are another big difference. Is bash at /bin/bash or /usr/bin/bash
Often different distro will have soft-link to the locations that other distro's use. Sometimes it's
hard to know where the real binary actually lives.
The locations of the libraries is another big difference. Some are at /usr/local/lib, some at /usr/lob, others at /usr/lib64. Most binaries are compiled to look certain places for certain version of certain libraries.
This is why you can't a copy binary from say.. Ubuntu, and have it run on fedora. (This does work sometimes, very rarely) First it's packaged wrong, second, it's compiled against different library versions that are likely in different locations than I am expecting them to be.
Then of course you have the whole architecture thing, i586 (32-bit) vs x86_64 (64-bit) vs ARM, vs PowerPC, vs Itanium, etc... binaries compiled for a specific processor generally won't work on other processors. (x86_64 is usually backwards compatible with i586)
Then you have all the little packages versions, bash 4.10 vs bash 4.12, python 2.7 vs python 3.8, binutils, coreutils, development libraies, etc... it gets complicated in a hurry.
All these versions depend on each other and you can't just throw something that requires a different version on your computer. This is why you can't take python3.8 from your Ubuntu 20 system and have it run on your old Ubuntu 16 system.
SuSE is different from either Debian or Redhat, it uses zypper and Yast2 to install software.
It has different versions of different libraries in different locations than the other other two.
Sometimes commercial Linux's such as redhat come with proprietary software. Linux may be open-source and free, but some of the packages that certain distro's include are not. Redhat for example comes with clustering software, SAN client software, Host Bus adapter software, Ethernet teaming/bonding software that many other distro's don't come with. It's included as part of the license, but it isn't "free".
Some distro's prefer a certain flavor of desktop environment. Some software wants to run under Gnome, some software wants to run under KDE, some software might want Unity or Enlightenment.
Most of the larger distro's support multiple desktops being installed at once. But not all of them.
Then you have systemd vs the old sysV init process manager scheme. Some distro's support it, I found it recently that some popular distro's still do not.
Keep in mind a lot of what we call "old software" was new at one time. My first Linux ran the 1.2 kernel on a 486 (32 bit) CPU with 32 MEG (not a typo, not GB) of RAM. The stuff we are running today will be considered old and outdated before you know it.
There is a lot more to say here... but this is already too long. I hope this helps.