Hi Paul,
Your question is actually very good and made me think for a while. Your approach would certainly work - a field somewhere in the segment header saying "now we're operating in TCP reliable and connection oriented mode", or "now we're operating in UDP unreliable and connectionless mode".
I do not have any definitive answer to your question why two standalone and separate transport protocols were created, instead of just one in which the reliability and connection-oriented operation could be switched on or off on demand. Nevertheless, the times when both TCP and UDP were designed were also times when Unix-based operating systems were widely used. In Unix, the general philosophy of any utility is to perform just a single thing and do it right. Think of basic commands like less, ls, cat, tar, gzip, find, grep, ... - all these are very tiny utilities, so to speak, but whatever they do, they do right. If you need more sophisticated tool, you go and create it by composing the existing tools. This has a big advantage - when developing a single tool, you focus just on one particular purpose, eliminating the complexity of integrated solutions and related bugs.
With protocols, I believe, the situation is similar. We could have a single monolithic protocol that would take care of every possible mode of communication - reliable, unreliable, connection-oriented, connectionless, with or without flow control, with or without congestion control, etc. But imagine the complexity, size and intricacy of such protocol and its implementation. If you were to implement it in C or any other suitable programming language in its entirety, you'd be tearing your hair out. The TCP itself is inordinately complex to do right already. If it was to integrate UDP's functionality, it would be simply impossible to maintain efficiently.
Also, it is worth mentioning that because TCP and UDP are separate protocols and UDP is so simple, it was possible to implement a basic IP+UDP driver that fits into a very limited space in yesterday's and today's EEPROMs and allows, for example, computers to boot via network (yes, they use IP+UDP+DHCP and TFTP drivers that are so small they fit into the small ROMs on network cards or motherboards), or recover a device after its firmware became corrupted (think Cisco routers and the ROMMON mode). This would not be possible if a single protocol encompassing both TCP and UDP behavior needed to be stuffed into those tiny ROMs - it would not fit. Today, the size is not such an issue but 10-15 years before, you were looking how to save every byte.
So this is my personal take on it - while it could work the way you suggest, for practical reasons proved by years of real-time deployment, it is more advantageous to have a separate protocol for a separate purpose.
Of course, feel welcome to ask further!
Best regards,
Peter
