Update the timeline for removing @import in the module system blog (#…

…651)

source/blog/024-the-module-system-is-launched.html.md

@@ -337,15 +337,22 @@ However, doing away with `@import` entirely is the ultimate goal for simplicity,
 performance, and CSS compatibility. As such, we plan to gradually turn down
 support for `@import` on the following timeline:
 
--   One year after both Dart Sass and LibSass have launched support for the
+-   ~~One year after both Dart Sass and LibSass have launched support for the
     module system _or_ two years after Dart Sass launches support for the module
     system, whichever comes sooner (**1 October 2021** at latest), we will
     deprecate `@import` as well as global core library function calls that could
-    be made through modules.
+    be made through modules.~~
 
--   One year after this deprecation goes into effect (**1 October 2022** at
+-   ~~One year after this deprecation goes into effect (**1 October 2022** at
     latest), we will drop support for `@import` and most global functions
-    entirely. This will involve a major version release for all implementations.
+    entirely. This will involve a major version release for all implementations.~~
 
-This means that there will be at least two full years when `@import` and `@use`
-are both usable at once, and likely closer to three years in practice.
+~~This means that there will be at least two full years when `@import` and `@use`
+are both usable at once, and likely closer to three years in practice.~~
+
+**July 2022**: In light of the fact that LibSass was deprecated before ever
+adding support for the new module system, the timeline for deprecating and
+removing `@import` has been pushed back. We now intend to wait until 80% of
+users are using Dart Sass (measured by npm downloads) before deprecating
+`@import`, and wait at least a year after that and likely more before removing
+it entirely.