Since I was the author of the proposal on the bugzilla but not able to edit this one, let's summarize and remove irrelevant stuff (the hard no to move to git is no longer valid).

Stricter coding, naming style.

For the moment there are high number of style issues in the API. Some symbols are SDL_lowerCased and some are SDL_UpperCased. Some are not even prefixed by SDL_.

Every functions that are tighed to a specific structure should:

Be prefixed by its name: SDL_Foo (object), SDL_FooOpen, SDL_FooDestroy, SDL_FooUpdate, etc.
Take the object as first argument: SDL_FooUpdate(SDL_Foo *, ...);

Getter and setters should be named as following:

• SDL_Namespace(Get|Set)What (e.g. SDL_Renderer(Get|Set)DrawColor)

Constructors and destructors should be named as following if applicable:

• SDL_NamespaceOpen (e.g. SDL_JoystickOpen)
• SDL_NamespaceDestroy (e.g. SDL_JoystickDestroy)

If objects are not meant to be dynamically allocated, the names "Init" and "Finish" or "Close" can also be used.

Proper semantic versioning.

SDL 2.0.9 version added sensor support, while it should be bugfix instead. The current versioning scheme makes too difficult to check what features were provided and when at a glance.

What did 2.0.1 provided? What 2.0.2 provided?

In the head of packagers, they feel like they are bugfixes while they've added new APIs!

The Semantic Versioning is the most appropriate versioning scheme for libraries.

• Major: massive breakage allowed in the API (not every year though, somewhat like every 5-6 years).
• Minor: improvements and new features added with API compatibility honored
• Patch: simple bugfixes

Removing useless platforms.

• arts: no longer used
• winrt: too, AFAIK

Fixing inconsistencies

If we have structs, then functions should always operate on them. Since C99, compound literals makes life easier while passing temporaries to functions.

• SDL_SetRenderDrawColor takes 4 ints
• SDL_SetPaletteColor take a SDL_Color object
• SDL_RenderDrawLine takes 4 ints
• SDL_RenderSetClipRect takes a SDL_Rect

The color handling is sometimes in 4 ints, sometimes SDL_Color.

Getting rid of dozens of buildsystems to unique one: CMake.

There are just too many build systems in the tree and that is too complicated for users, developers and packagers. Also, having only one for a portable library that SDL is, makes difficult to merge all checks/operations in all build systems.

Also, lots of people do not rely on the SDL CMake configuration package files provided as autoconf does not install them. Having CMake only will simplify the integration and maintainance.

Use doxygen documentation to avoid outdated information on the wiki

I've literally spent 3 hours to document the sensor API on the wiki. That's a big waste of time. SDL headers are already almost documented in doxygen, it should be completed with missing bits and the only source of truth.

Changing something in one enum results in editing the wiki as well.

Rename pkg-config files

The SDL pkg-config file is sdl2 while addons are SDL2_*.

Making addons first class citizen and built from the same source tree with proper naming

The SDL addons feel they are separate projects as they still do not have any public visibility from the libsdl.org website. At a glance, a newcomer don't even know these libraries exist.

They have the same troubles as the above paragraphs (cmake, consistency, etc.).

I propose the simple inclusion of these addons with a new naming scheme for them and a simpler API. Also, they will be available as separate shared/static libraries controlled at build time. Thus, people who don't need SDL_mixer or SDL_ttf can simply not build/link theme.

SDL_ttf new API

Every functions start with SDL_Font.

• SDL_Font (struct)
• SDL_FontStyle (enum SDL_FONT_SOLID, SDL_FONT_SHADED, SDL_FONT_BLENDED)
• TTF_Init -> SDL_FontInit()
• TTF_OpenFont* -> SDL_FontOpen*
• TTF_(Get|Set)Font* -> SDL_Font(Get|Set)*
• TTF_FontHeight -> SDL_FontGetHeight
• TTF_FontAscent -> SDL_FontGetAscent
• TTF_FontDescent -> SDL_FontGetDescent
• TTF_FontLineSkip -> SDL_FontGetLineSkip
• TTF_FontFaces -> SDL_FontGetFaces
• TTF_GlyphIsProvided -> SDL_FontIsGlyphProvided
• TTF_GlyphMetrics -> SDL_FontGetGlyphMetrics
• TTF_SizeText -> Should be removed, UTF-8 is the standard
• TTF_SizeUTF8 -> SDL_FontTextMetrics
• TTF_SizeUNICODE -> Should be removed, UTF-16 is deprecated
• TTF_Render* -> SDL_FontRender(const char *, SDL_FontStyle) (UTF-8 only)

SDL_image new API

Every function start with SDL_Image.

• SDL_ImageFormat (enum SDL_IMAGE_(CUR|ICO|BMP|PNM|...))
• IMG_Init -> SDL_ImageInit()
• IMG_Load -> SDL_ImageOpen(const char *path)
• IMG_Load_RW -> SDL_ImageOpen_RW
• IMG_LoadTyped_RW -> SDL_ImageOpenTyped_RW(SDL_RWOps *, SDL_ImageFormat)
• IMG_is* -> SDL_ImageGetType (returns SDL_ImageFormat)

SDL_mixer new API

Basic functions start with SDL_Mixer.

• Mix_Init -> SDL_MixerInit
• Mix_OpenAudio -> SDL_MixerOpen
• Mix_CloseAudio -> SDL_MixerClose
• Mix_GetNumChunkDecoders -> SDL_MixerGetNumChunkDecoders
• Mix_GetChunkDecoder -> SDL_MixerGetChunkDecoder

Channel and groups functions

• Mix_AllocateChannels -> SDL_ChannelsAllocate
• Mix_ReserveChannels -> SDL_ChannelsReserve
• Mix_Group* -> SDL_ChannelGroup*
• Mix_HaltGroup -> SDL_ChannelGroupHalt
• Mix_Volume -> SDL_ChannelVolume
• Mix_PlayChannel -> SDL_ChannelPlay
• Mix_PlayChannelTimed -> SDL_ChannelPlayTimed
• Mix_FadeInChannel -> SDL_ChannelFadeIn
• Mix_FadeInChannelTimed -> SDL_ChannelFadeInTimed
• Mix_Pause -> SDL_ChannelPause
• Mix_Resume -> SDL_ChannelResume
• Mix_HaltChannel -> SDL_ChannelHalt
• Mix_ExpireChannel -> SDL_ChannelExpire
• Mix_FadeOutChannel -> SDL_ChannelFadeOut
• Mix_ChannelFinished -> SDL_ChannelHasFinished
• Mix_Playing -> SDL_ChannelIsPlaying
• Mix_Paused -> SDL_ChannelIsPaused
• Mix_FadingChannel -> SDL_ChannelGetFading
• Mix_GetChunk -> SDL_ChannelGetChunk

Chunk functions

• Mix_LoadWAV -> SDL_ChunkOpen
• Mix_LoadWAV_RW -> SDL_ChunkOpen_RW
• Mix_QuickLoad -> SDL_ChunkQuickOpen
• Mix_QuickLoad_RW -> SDL_ChunkQuickOpen_RW
• Mix_FreeChunk -> SDL_ChunkDestroy
• Mix_VolumeChunk -> SDL_ChunkGetVolume

Music functions

• Mix_GetNumMusicDecoders -> SDL_MusicGetNumDecoders
• Mix_GetMusicDecoder -> SDL_MusicGetDecoder
• Mix_LoadMUS -> SDL_MusicOpen
• Mix_FreeMusic -> SDL_MusicDestroy
• Mix_PlayMusic -> SDL_MusicPlay
• Mix_FadeInMusic -> SDL_MusicFadeIn
• Mix_FadeInMusicPos -> SDL_MusicFadeInPos
• Mix_HookMusic -> SDL_MusicHook
• Mix_VolumeMusic -> SDL_MusicVolume
• Mix_PauseMusic -> SDL_MusicPause
• Mix_ResumeMusic -> SDL_MusicResume
• Mix_RewindMusic -> SDL_MusicRewind
• Mix_SetMusicPosition -> SDL_MusicSetPosition
• Mix_SetMusicCMD -> SDL_MusicSetCommand
• Mix_HaltMusic -> SDL_MusicHalt
• Mix_FadeOutMusic -> SDL_MusicFadeOut
• Mix_HookMusicFinished -> SDL_MusicSetHookFinished
• Mix_GetMusicType -> SDL_MusicGetType
• Mix_PlayingMusic -> SDL_MusicIsPlaying
• Mix_PausedMusic -> SDL_MusicIsPaused
• Mix_FadingMusic -> SDL_MusicIsFading
• Mix_GetMusicHookData -> SDL_MusicGetHookFinished

Effect functions

• Mix_RegisterEffect -> SDL_EffectRegister
• Mix_UnregisterEffect -> SDL_EffectUnregister
• Mix_UnregisterAllEffects -> SDL_EffectUnregisterAll
• Mix_SetPostMix -> SDL_EffectSetPostMix
• Mix_SetPanning -> SDL_EffectSetPanning
• Mix_SetDistance -> SDL_EffectSetDistance
• Mix_SetPosition -> SDL_EffectSetPosition
• Mix_SetReverseStereo -> SDL_EffectSetReverseStereo

SDL_net

To my humble opinion, this library should be removed as they are many networking library in C including POSIX.

Here are my thoughts...

Stricter coding, naming style.

Generally agreed. We'll need to create an sdl2-compat library similar to sdl12-compat that preserves the old ABI for older programs while continuing new development in sdl3 with a more consistent API.

Proper semantic versioning.

We'd have to look at how library versioning is done on Linux. We need to guarantee that older binaries continue to run with newer versions of SDL, and the current versioning system does that. The version is actually generated by using the scheme in autotools:

# Making releases:
# Edit include/SDL_version.h and change the version, then:
#   SDL_MICRO_VERSION += 1;
#   SDL_INTERFACE_AGE += 1;
#   SDL_BINARY_AGE += 1;
# if any functions have been added, set SDL_INTERFACE_AGE to 0.
# if backwards compatibility has been broken,
# set SDL_BINARY_AGE and SDL_INTERFACE_AGE to 0.

and it turns out that this guarantees binary compatibility in the way that we need.

In terms of knowing when functions have been added, we now include that information in the headers and wiki so it's easy to find.

Removing useless platforms.

WinRT is still used by the UWP code for Windows Store games and Xbox, so it will continue to be relevant.

Fixing inconsistencies

If we have structs, then functions should always operate on them. Since C99, compound literals makes life easier while passing temporaries to functions.

We should review what compilers and platforms are still supported. I'm still occasionally surprised that people are still using platforms that require C89 code. But I agree we should be consistent here, with an eye toward the most efficient and easy to use interfaces.

Getting rid of dozens of buildsystems to unique one: CMake.

I think we should bite the bullet and just pick CMake over autotools. Maintaining two separate configuration and build systems is too high a tax, and enough people (and platform maintainers) are using CMake that it seems like the right choice for SDL 3. That said, we should still keep the Visual Studio and Xcode projects for people who are more comfortable using the IDE's.

Use doxygen documentation to avoid outdated information on the wiki

This is already done. Ryan has created a bridge between the headers and wiki so each side is automatically updated by changes in the other side.

Rename pkg-config files

👍

Making addons first class citizen and built from the same source tree with proper naming

The problem here, and the reason why the SDL addons have lagged behind in terms of releases, is these depend on a lot of third party libraries that are time consuming to build and maintain in-tree. git submodules may make this easier though, so this is definitely worth reviewing. The ability to easily add modules to your project with CMake makes this much more viable in the future.

I generally agree with the naming suggestions for the third party APIs above.

SDL_net

Agreed. There are lots more tools out there now than there were when this library was created.

Proper semantic versioning.

We'd have to look at how library versioning is done on Linux. We need to guarantee that older binaries continue to run with newer versions of SDL, and the current versioning system does that. The version is actually generated by using the scheme in autotools:

Well semantic versioning does not really care about ABI, it only cares about API in the sense that a program that uses a specific minor version may get new features but with never incompatibilities.

Fixing inconsistencies

If we have structs, then functions should always operate on them. Since C99, compound literals makes life easier while passing temporaries to functions.

We should review what compilers and platforms are still supported. I'm still occasionally surprised that people are still using platforms that require C89 code. But I agree we should be consistent here, with an eye toward the most efficient and easy to use interfaces.

The C99 compound literals are for the user side, SDL does not need to have C99 support. This just means that if we take structures as argument the user can do:

SDL_DoSomethingWithARectangle(&(const SDL_Rect){.w = 10 }));

Getting rid of dozens of buildsystems to unique one: CMake.

I think we should bite the bullet and just pick CMake over autotools. Maintaining two separate configuration and build systems is too high a tax, and enough people (and platform maintainers) are using CMake that it seems like the right choice for SDL 3. That said, we should still keep the Visual Studio and Xcode projects for people who are more
comfortable using the IDE's.

CMake generates proper Visual Studio and Xcode projects. Visual Studio even has a nice integration.

Making addons first class citizen and built from the same source tree with proper naming

The problem here, and the reason why the SDL addons have lagged behind in terms of releases, is these depend on a lot of third party libraries that are time consuming to build and maintain in-tree. git submodules may make this easier though, so this is definitely worth reviewing. The ability to easily add modules to your project with CMake makes this much more viable in the future.

We don't incorporate third party libraries. That's generally a very bad thing to do because of ABI incompatibilities (and there are too much systems and architectures). This just means that we conditionally add support to a feature if present. For example, if user selects MP3 support, then SDL_mixer will be linked against the system mad/mpg321 library. Nothing more :)

Once SDL targets the 3 version, please write a ping here so that I can start massive refactoring :)

Make SDL_main a header-only lib

Right now using SDL_main can be painful, especially with MinGW: There you have to link -lmingw32 -lSDL2main -lSDL2 in that exact order (you can add other libs in between, but libmingw32 must be before libSDL2main, and libSDL2main must be before libSDL2) - especially getting libmingw32 there isn't trivial, see

Another (also Windows-specific) problem is that .lib files generated by MinGW don't work with modern MSVC versions ("module unsafe for SAFESEH"). For the SDL2.lib only used for linking the DLL it's not that bad, because it can relatively easily be generated from SDL2.dll (create a .def with mingw's gendef SDL2.dll and then use lib.exe /machine:x86 /def:SDL2.def /out:SDL2.lib in the VS developer console to generate the lib) - but that doesn't help for SDL2main.lib, which is a proper static lib and not just this stub-thing used on Windows to link DLLs.
So binary builds of SDL2 for Windows that have been built with MinGW aren't really compatible with MSVC, mostly because of SDL2main.

These problems would vanish if SDL2main was a header-only lib that you just #include in your source file that implements int main(int argc, char** argv) (and only there). It could still do its #define main SDL_main trick, and it could contain the platform-specific SDL_main code (or nothing at all for most of the platforms which don't use it). SDL.h wouldn't #include <SDL_main.h> anymore (maybe it shouldn't do that either way).
Like SDL_config.h it would be generated when SDL is built (or probably just copied from some dir in src/ to include/).

As a nice side-effect, it would make it clearer when it is used an when not:
Right now if you don't want to use it on e.g. Windows, you need to #define SDL_MAIN_HANDLED before #include <SDL.h> (or in your build process), which is not obvious - with SDL_main as a header-only lib, you'd just do nothing, and do #include <SDL_main.h> if you want to use it.
Also I think that right now if you have any variable (or function, enum member, ...) called main - in any file that just includes SDL.h, not just the one with main() in it! - and that #define main SDL_main is active on your platform, that variable will be renamed as well, which could lead to confusion..

Furthermore, it would make it easier to copy the SDL_main implementation into your own source and adjust it to your needs.

Make SDL_main a header-only lib

I like this idea. @icculus, what do you think? Is this something we can implement in 2.0.22?

I like the idea but would keep this in the SDL 3 bucket.

Another idea for SDL3:

• Remove all the complexity around removing API entry points. You can disable subsystems, but the API entry points will remain, with dummy implementations.

IMPORTANT: We will also need sdl20-compat from the very beginning.

BTW, are there plans for a SDL2.1 before SDL3?
(If so, making SDL_main a header-only lib only requires very minor adjustments to applications using SDL2 - adding one #include in one file - so it IMO could be done in 2.1)

SDL3 is the next major ABI breaking revision - what we previously were calling SDL 2.1.

So I'm just catching up on this, so I wanted to throw in my current opinions.

I want to be clear that when suggesting big changes my instinct is to say no, and--as you can see from my "hard no" about GitHub--I don't make all the decisions and sometimes it turns out I'm proven wrong.

Stricter coding, naming style

I agree that SDL2 is extremely inconsistent in this regard, and we should definitely clean that up for SDL3, but I do not think it has to be as rigid as SDL_SubsystemVerbSubject.

Semantic versioning

SDL versioning can change, but semantic versioning is deeply overrated in my opinion.

We tend to never break even minor interfaces before we decide to change everything at once, and we do this less than once a decade in general. In the meantime, we add stuff all the time and constantly fix bugs and occasionally we bundle this up as production ready. We don't generally put out releases more than a few times a year.

Please do not reply with how the semver philosophy should be applied to this. It's just dogma, as far as I'm concerned.

Remove useless platforms

Every time I try to get rid of a platform or backend, someone pops up to say they still need it.

For various backends, this is largely harmless, because they can be ignored and even bitrot without a serious cost to the project.

But even things like Sony PSP and OS/2 have active users and maintainers. A lot of things would be hard to delete, is all I'm saying.

Arts can definitely go, though. :)

Build systems

I would love to drop to just CMake (or an equivalent, if there's a better option), but there is a value in telling people they can just double-click the Visual Studio project file and build. Even though CMake can generate vs project files, this adds friction for the average windows and Mac developer.

Between CMake and autotools though, CMake sucks less and we frequently have issues where we have to fix problems in one or the other, so dumping autotools is okay with me.

It might be interesting to find a way to automate this on Windows/Mac, so the user double clicks a small included .exe and it gets CMake installed if necessary and generates the project files.

Use doxygen documentation to avoid outdated information on the wiki

This is done. Changes to Doxygen comments in the headers automatically generate Wiki changes now and vice-versa. It generates manpages now, too!

This doesn't cover anything but functions...structs and stuff are not bridged, but this can change.

Making addons first class citizen and built from the same source tree with proper naming

100% no.

Get rid of SDL_net

100% yes.

Here's an old Trello board about ideas for future improvements to SDL that got propped up at some point, I think to collect stuff that was mentioned around other places. Not all of it is still relevant (or was ever necessarily good)...

https://trello.com/b/sXcrlXCD/sdl-wishlist

...but it's probably worth sifting through. I've made it read-only to prevent the discussion from migrating to there.

I might have missed mention of it, but for an abi breaking revision i would love to see a more consistent access to platform-dependent things.

The main thing that made me think about this was this issue over here (which, i realize, is another shameless bump, sorry x.x): #3360

The most use out of this would be in the rendering system - access window handles for video, texture and context access for the renderer.

Where to draw draw the line though?
While i never needed access to the stuff governing the event loop it might be easy to argue "hey, the rendering system got functions to pull out everthing from opengl to vulkan, we want it too!", and i don't know if thats a path one should walk.

I think the plan is to remove SDL_GL_BindTexture(), see #2124 (and IMHO it's the right thing to do).

HOWEVER, icculus is working on a 3D API (see https://discourse.libsdl.org/t/future-3d-api/33485/23), and if I recall correctly, there were plans to allow interaction between that and SDL_Render (I guess SDL_Render would use the new 3D API under the hood).

I created #3360 initially to think about an alternative to just removing stuff.
Anyway, i completely forgot about "Letting people mix and mingle" point in the post on the list though, when writing my suggestion above. It does supersede everything i would ever want, so, ugh oops?

Don't mind me, have a great day :D

BTW, regarding that earlier post from @markand

The C99 compound literals are for the user side, SDL does not need to have C99 support. This just means that if we take structures as argument the user can do:

SDL_DoSomethingWithARectangle(&(const SDL_Rect){.w = 10 }));

Designing an API for compound literals + designated initializers hurts its usability IMO, especially for C++:

• C++ only supports designated initializers (that {.w=10, .h=20} syntax) in C++20 and newer, which is much too new to demand, IMO
• Unlike C, when using them in C++ you must use the correct order of the initialized struct members ({.h=20, .w=10} is illegal for struct SDL_Rect { int x; int y; int w; int h; }; because .w comes before .h). That makes using them more tedious.
• Your example takes the address of an r-value (I assume SDL_DoSomethingWithARectangle() takes a const SDL_Rect* as an argument). That seems to work in C, but is illegal in C++, see https://gcc.godbolt.org/z/7eY6rEv38

BTW, regarding that earlier post from @markand

The C99 compound literals are for the user side, SDL does not need to have C99 support. This just means that if we take structures as argument the user can do:

SDL_DoSomethingWithARectangle(&(const SDL_Rect){.w = 10 }));

Designing an API for compound literals + designated initializers hurts its usability IMO, especially for C++:

As I have mentioned, its just about adding consistency with what functions should take. Some functions at the moment use several ints and some use SDL_Rect. That's it. How do you pass the structure is up to you.

Async rwops: #1374

High DPI consistency - most of these are assuming SDL will stick with DPI-scaled units for window position/size (which I personally prefer):

• float coordinates available for mouse positions (comments of New High DPI Support API is needed #2119).
• APIs or fields to query the DPI scale or size-in-points vs size-in-pixels of a particular display mode for a monitor (comments of New High DPI Support API is needed #2119). I'm coming from an Apple-centric perspective for this so I'm not sure if it makes sense across operating systems.
• APIs to query the active or recommended DPI scale of a display?
• Make Android behave the same as other operating systems with respect to SDL_WINDOW_ALLOW_HIGHDPI and DPI-scaled units (Support HW scaler in Android #1677).
• Clean up any inconsistencies between DPI scaling behaviour across operating systems - especially Windows vs the rest. I'm not sure where we'll be with high DPI on Windows by the time SDL 3 rolls around, but I hope Eric's work will be merged into SDL before then. (comments of New High DPI Support API is needed #2119 again).

Some of these could be done before a theoretical SDL 3 because they don't all break or change APIs, but it's probably best to think of them all in concert for SDL 3 in any case.

System notification API: #1932

Drag and drop improvements: #5292

Don't clamp IME input to fit in an event structure: #5363

Reconsider multiple audio device opens: #5485

Throwing this out there because it's something I consistently ran into while working on Wayland, and is a consistent pain point for other backends like X: The SDL_Window API spec should be modified to make all changes buffered, with a CommitWindowChanges call to push everything at once.

This fixes the main problem we've been having lately, which is that the order of window calls can finally stop mattering and SDL can enforce consistent behavior without having to fight the OS as much. On top of being a pretty major bugfix (see the numerous issues for this, usually it's when modifying a window size after leaving fullscreen) it's also an optimization; Wayland for example has to commit the window surface every time a call is made, while in reality we shouldn't have to do it more than once (or twice if you count presentation) per frame. Right now compositors hate us for doing it like this, and when you actually look at the interaction at a low level it's easy to see why (see #4563).

This is similar to the old SetVideoMode without forcing SetVideoMode - someone could make multiple CommitWindowChanges calls if they absolutely needed to, while still knowing the consequences of not optimizing the batch of changes.

Would narrowing down the Actions make it any faster...? Usually when I'm checking CI I just look at the subtasks and skip the ones that don't matter too much, and AFAIK it doesn't affect performance. Should we just split the most popular Windows/macOS/Linux build configs into their own CI files?

More or less, that's what I'm proposing, but GitHub Actions also has a cron-style interface, so we can just blast out a "build everything you can think of" on a once-a-day or whatever basis that's divorced from the smaller set of checks we want to see immediately and in-line.

As for ignoring them: it runs in parallel to some degree, but it stops all currently-running builds if one of them fails, afaik, so I also want to avoid not knowing if Mac is working immediately because the PlayStation 2 port broke 100 commits ago.

Should they also be SDL3_WHATEVER so that SDL 1/2 and SDL 3 can be controlled independently?

Modulo some name changes, you pretty much want the same thing between each version of SDL, and in the compat scenario, you only ever deal with one implementation...whereas with the dynamic API, you have two incompatible interfaces operating in parallel and might want to override them both.

Everybody seems to be in favour of getting rid of SDL_net but as somebody who makes heavy use of it, across a wide range of platforms, I'd like to understand better what the replacement is expected to be, especially on Android and iOS. If the idea is to use Posix socket functions everywhere that's fine, I have no objection, but are they straightforwardly available on mobile platforms?

I'm going to write this here, and if it makes sense we can reference this in a new SDL_net issue, but let's not carry on discussion about this in this thread.

I will say, upfront, that I expect we are going to be buried in SDL3 work, while still attempting to keep up maintenance on SDL2 while we do it, for the foreseeable future, so I just don't see an upgrade to SDL_net happening for a long time unless someone else steps up to do it.

To answer this question: yes, everything uses BSD Sockets now, or WinSock, which is 95% BSD Sockets and the rest can be protected by a small #ifdef block at the start of the code that conceals the differences.

The hairiest places are:

• Emscripten, which offers a BSD Sockets API but webpages cannot open sockets to random internet addresses, so it fakes it with WebSockets, which is a reliable bidirectional stream like a TCP socket, but isn't TCP, so you can't just connect to port 25 with a WebSocket and talk SMTP to a mail server. But here, it's not something we'd be able to abstract in SDL_net or anything else...you really have to design for it, if you can design for it at all. It's a mess. One could make a game that uses WebSockets on all platforms, as they are built on top of TCP streams, in which case they can be used cleanly from Emscripten, and RTSP replacing UDP in roughly the same way...but these are complicated, and in both cases probably require encryption to work at all. And now you're writing a very large and scary piece of code.
• Encryption, at any layer, is a pain in the butt, for lots of reasons.
• There's a lot of things that aren't real time games that don't want TCP or UDP...they want HTTP. libcurl is pretty complex but handles all sorts of wild (and yet common) scenarios, but it's a big dependency that can be hard to build...so it makes sense to push this off to various system APIs, since Windows, Mac, Android, etc, all offer this and handle SSL, too. But then you end up writing this five times, which is a scenario where SDL tends to be helpful.

Okay, I think I've split out most relevant things to their own issues, thus ending this megathread. If you don't see your thing mentioned in a separate issue, above, then I either missed it, thought it was already fixed, thought it was being handled by an existing issue, or made an executive decision to say no. :)

But I can't really stop you in that last case, so you should always feel welcome to open a new issue yourself if you feel strongly about it!

This thread is being closed now, though, so don't dump any more ideas in here, or they risk being forgotten. Now that we're doing SDL3 for real, just go ahead and open a new issue.

Thanks everyone!