First, look at https://www.erlang.org/eeps. The "S/$version" statuses are for proposals that are finalized and implemented in a version of Erlang. For example, "SF/27.0 66 25-Sep-2023 EEP 66: Sigils for String Literals" shows that EEP 66 is part of the language as of Erlang/OTP 27. Then, go to erlang.org and view release notes for major releases - most of the smaller work does not go through the EEP process. Finally, not all release notes are available or mention the feature you're interested in, but the repo on github goes all the way back to OTP_R13B03, so I recommend cloning that and searching the git log. The otp git is also useful for quickly confirming release dates:

$ git checkout OTP-25.0
$ git log|head -5
commit 4ed7957623e5ccbd420a09a506bd6bc9930fe93c
Author: Erlang/OTP <otp@erlang.org>
Date:   Tue May 17 21:29:45 2022 +0200

    Updated OTP version

1. Funs can have names now, and be recursive without a combinator (2012)
2. HiPE has been replaced (2021 May)
3. The erlang-questions mailing list is gone (2022 April)
4. hex.pm is the Erlang package repository (2020 ?)
5. You can no longer compile Mercury to Erlang (2024)
6. Erlang has maybe expressions (2022), enabled by default in OTP 27 (2024)
7. Erlang has really good perf support
8. It's now much easier to use the selective receive optimization (OTP 24, 2021)
9. Erlang documentation no longer requires Apache FOP to build (OTP 27, 2024)
10. The 'slave' module has been replaced with 'peer' (2021)

HiPE has been replaced

You used to have to erlc +native file.erl or similar to get native builds. In OTP 24 this was completely replaced and now you always get JIT compilation if the platform's capable of it - with no asking.

1> erlang:system_info(emu_flavor).
jit

The erlang-questions mailing list is gone

The archives remain useful, especially for searching, but no further posts to it were permitted. erlang.org has a community page with some alternatives. The slack is easy to get into but slack's payment model prevents you from seeing posts older than 90 days, making it useless for searching.

Rationale:

The major reason for closing the ML is that the OTP team have not enough resources to moderate the ML and also that we want to focus Erlang discussions to one channel.

hex.pm is the Erlang package repository

slack remark: "If it's not on hex.pm it doesn't exist."

I couldn't get the fossil support to work, but apparently it is possible.

You can no longer compile Mercury to Erlang

Покойся с миром. I never used it, and you didn't either, since it was abandoned in 2016 and never reliable, but it might've been nice.

You can still make a Mercury NIF.

Funs can have names now, and be recursive without a combinator

EEP 37

4> F = fun Fact(1) -> 1; Fact(X) when X > 1 -> X * Fact(X - 1) end, F(40).
815915283247897734345611269596115894272000000000

The 'slave' module has been replaced with 'peer'

The peer module has updated functionality, but that's obviously not the reason for the change. If this bothers you, consider:

1. Master/slave was always engineering jargon that didn't map at all closely to any human relationship. If your impulse is to argue that origin/peer doesn't describe the Erlang relationship as well, e.g. "what peer can *control* another peer?", I think that if you challenge that thought a bit you'll immediately find absurd examples in jargon that you already accept. It's just jargon, and as jargon it's fine.
2. If it had been the 'peer' module all along, you wouldn't miss it. The change itself is not really what bothers you.
3. The declared reason for the change, that 'slave' has become unprofessional and off-putting speech, isn't completely wrong. It's an example of a tyranny of the minority in operation. The people who care about purging this word, they just care more about doing that than anyone cares about stopping them from doing it, so they win. The only resulting slippery slope is that more changes against overwhelmingly tolerant opposition may happen.