no-implicit-prelude-import.md

@@ -92,6 +92,15 @@ by making a more level playing field.
 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