no-implicit-prelude-import.md

@@ -111,6 +111,32 @@ It may also be beneficial to EDSL designers, who wish to reuse `Prelude`
 names for different functions.
 
 
+
+It is possible that this would lead to a large number of alternative
+Preludes, all slightly different.
+On the other hand, perhaps this has already happened
+([ 1](http://hackage.haskell.org/package/basic-prelude)
+[ 2](http://hackage.haskell.org/package/ClassyPrelude)
+[ 3](http://hackage.haskell.org/package/classy-prelude)
+[ 4](http://hackage.haskell.org/package/custom-prelude)
+[ 5](http://hackage.haskell.org/package/fugue)
+[ 6](http://hackage.haskell.org/package/general-prelude)
+[ 7](http://hackage.haskell.org/package/gofer-prelude)
+[ 8](http://hackage.haskell.org/package/interlude)
+[ 9](http://hackage.haskell.org/package/modular-prelude)
+[ 10](http://hackage.haskell.org/package/modular-prelude-classy)
+[ 11](http://hackage.haskell.org/package/numeric-prelude)
+[ 12](http://hackage.haskell.org/package/prelude-extras)
+[ 13](http://hackage.haskell.org/package/prelude-generalize)
+[ 14](http://hackage.haskell.org/package/prelude-plus)
+[ 15](http://hackage.haskell.org/package/prelude-prime)
+[ 16](http://hackage.haskell.org/package/simpleprelude)
+[ 17](http://hackage.haskell.org/package/yap)), in which case lowering the barrier
+to using alternative Preludes may help determine a winner. However, it seems more
+likely that the vast majority of developers will continue to import modules from
+`base` instead, rather than add a dependency on another library.
+
+
 ## Related issues