Reword async deep dive: note it merits future research

Instead of promising a planned deep dive post, acknowledge the area
merits deeper investigation and suggest it as a task for the future
User Research team.

Author: nikomatsakis

content/what-do-people-love-about-rust.md

@@ -156,7 +156,7 @@ For Rust to provide that "trusted tool that will help you tackle new domains" ex
 
 > "We generally use Rust for services, and we use async a lot because a lot of libraries to interact with databases and other things are async. The times when we've had problems with this is like, um, unexplained high CPU usage, for example. The only really direct way to try to troubleshoot that or diagnose it is like, *OK, I'm going to attach GDB and I'm gonna try to see what all of the threads are doing*. GDB is -- I mean, this is not Rust's fault obviously -- but GDB is not a very easy to use tool, especially in a larger application. \[..\] And with async, it's, more difficult, because you don't see your code running, it's actually just sitting on the heap right now. Early on, I didn't actually realize that that was the case." -- Experienced Rust developer at a company using Rust and Python
 
-Async is important enough that we plan to do a "deep dive" post to cover the details of what we heard. But async Rust is also an area where a future User Research team (as proposed in our first post) could do a dedicated set of interviews.
+Async is important enough that it merits a deep dive. Our research revealed a lot of frustration but we didn't go deep enough to give more specific insights. This would be a good task to be undertaken by the future User Research team (as proposed in [our first post](https://blog.rust-lang.org/2025/12/03/lessons-learned-from-the-rust-vision-doc-process/)).
 
 ### Example: The wealth of crates on crates.io are a key enabler but can be an obstacle