--- a/doc/EFR-rationale	Sun Dec 11 00:56:17 2022 +0000
+++ b/doc/EFR-rationale	Sun Dec 11 03:25:21 2022 +0000
@@ -80,3 +80,20 @@
 for encoder state and another unified struct for decoder state - but the problem
 of poor performance (significantly worse than opencore-amrnb) still remains for
 now.
+
+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.