Stop caring about syntax and start caring about semantics. For example
> if (a == (10 || 20 || 30) || b == a) && c { }
I get what you're after, but don't optimize syntax for bad code. `a in [10, 20, 30, b] and c` makes a lot more sense to me conceptually than trying to parse nested binary operators, especially when you consider the impact on type checking those expressions.
> async function will be called from no async function but no async/await keyword. If you want to block main thread then block_main() function will be used. block_main() /* operations */ unblock_main()
Think very carefully about the concurrency model of your language before thinking about how the programmer is going to express it. In particular, this model leaves a footgun to leave a program in invalid state.
> What are the features you found or you need in a programming language?
The biggest misdesigns I see in languages are a result of PL designers pushing off uninteresting but critical work so they can explore interesting language semantics. Like the compile/link/load model and module resolution semantics have far more impact over the success and usability of any new language (because they empower package management, code reuse, etc) and the details are hairy enough that taking shortcuts or pushing it off until later will kneecap your design.