It'd have a small number of reserved keywords. It'd read top-to-bottom without hidden control flows. Editor & toolings won't be necessary but will add progressive enhancements to development experience when available. It'd be easy to tokenize and parse. No syntax sugars.
The compiler will enforce Hungarian notation for all variable names. `iSize` will be an integer the same way `strName` is a string. The type information is never hidden away. Declare constants the same way, but with SCREAMING names. The const-ness is never hidden away.
Functions are of higher-order but first-class. Declare functions the same way, but with fn suffix. Functions don't necessarily need to be pure, but pure ones will be optimized. Async-await is automatic and the compiler will just optimizes it away when you don't need to. No function colorings.
The type system must be flexible enough for me to be able to design complex algebraic data types and sum types. Pattern matching is a must have in that case. I have no idea how the system would be like. But I want it invisible enough that it doesn't get in my way about 75% of the time. I want to make a software, not write poetic programs.
No meta programming. I do not like the way it is done currently in almost all programming languages. But I do understand it's much needed. A new way of doing it must be figured out.
Everything should be explicit. Needs to allocate? Get an allocator. Have an exception? Return it. Set boundaries where compiler can step in to perform optimizations.
Backward compatibility of the language design and the compiler shouldn't get in the way of the language design's potential. The language design and the compiler will get better with time, but people won't rewrite their programs every year. The standard to be maintained is that programmers should be able to incrementally migrate to newer language versions one dependency at a time, one file at a time, heck even one function at a time. Most languages fail this. See JS with CJS/ESM mess for example.
Oh, also file paths should always be POSIX-y. No `use a::b::c;` for imports. No aliased `@a/b/c` paths. Just plain, absolute or relative file paths that I could follow simply in any text editor without language specific toolings.