--- a/doc/EFR-rationale	Wed Apr 17 22:08:49 2024 +0000
+++ b/doc/EFR-rationale	Wed Apr 17 22:45:27 2024 +0000
@@ -84,16 +84,14 @@
 Future roadmap
 ==============
 
-If someone is implementing a DSP vocoder block for a GSM MS or a network-side
-speech transcoder that needs to support all standard GSM codecs, at some point
-they will need to implement both EFR and AMR.  Given the close relation between
-these two codecs (they are not perfectly compatible as we started out saying,
-but they are still very closely related), keeping two entirely separate library
-implementations for AMR and EFR will be very inefficient in the long run, and a
-nightmare to get them to perform equally well.  It seems to me (Mother Mychaela)
-that the correct solution will be to produce a single codec library that
-implements both AMR and EFR, probably by starting with an AMR library and
-extending it with special modes to handle those aspects where EFR differs.  It
-is my forecast that we are going to end up doing something along these lines in
-Themyscira - but it will be much later down the road; for the time being, our
-initial version of ThemWi will only support FR and EFR, but not AMR.
+When this article was originally written in late 2022, my thoughts were that we
+would go in the direction of a single library supporting both AMR and EFR,
+sharing most code in common and handling the differences between EFR and MR122
+similarly to how most proprietary implementations have done it, following the
+"alternative" of GSM 06.54 chapter 10.  However, that plan has been revised;
+our current approach (as of 2024-04) is that we are developing a separate
+library for AMR (libtwamr, librifying 3GPP AMR code in the same way how we
+librified ETSI EFR in libgsmefr), while libgsmefr remains as it is, a pristine
+implementation of GSM-EFR in its *original* bit-exact form.
+
+Please refer to AMR-EFR-philosophy article for more information.