That still sounds like mission statements. Many enough languages have similar missions and their plans to achieve them would vary a lot. I'll assume you are still figuring them out then, and share my humble opinions.
"Simple"---and yet usable---is very hard to define and achieve. If the language has to fit all domains, it seems that the best approach is to identify versatile, multi-use features (better explained by Guy Steele's Growing a Language talk). And such features are relatively uncommon! So most languages tend to have many features only for specific uses and pray that they don't clash with other features, i.e. ditching the simplicity. It is not really impossible, but I'd rather have it as a guiding principle other than a mission.
"Fast to compile" is good to have, but I hope you to use it just as a guide as well. The critical threshold is the apparent interactivity (about 100 ms), and anything faster than that is not worthwhile as is. Slow languages can also create an illusion of interactivity with many efforts (e.g. incremental compilation), so you would rather want to identify and avoid the global cause of latency. For example header files have a large impact on C/C++'s compilation speed, even when everything is cached and using loglinear algorithms or faster. I think V got a general idea right, so don't be too fixated about concrete numbers.
"C/C++ perf" needs more quantification. First of all, many C/C++ programs are actually slow for many reasons. It is just that many performance-sensitive programs were also written in C/C++. Many other languages tend to use other related statements like "no language runtimes", "no hidden control flows" or "no allocations". Not very satisfactory, but still better because they imply actual actions. And please be aware that this goal is in general directly contradictory to the simplicity, another reason to ditch it...
"Fits all domains" is what I'm most unsure about. I believe attempts to write everything in V are related, but they won't ever be sufficient (let's talk about writing a proof-certified mathematical routine :-). Many languages provide the extensibility as a primary solution, but it is not enough---I mean, unless you think PyTorch tracing CPython bytecode and producing a fused CUDA kernel as extensibility. Many domains do share common requirements in terms of programming, so multi-paradigmatic approaches would scale better... unless new programming paradigm can be hard to retrofit to the existing language. (Lisp doesn't count because it generates a family of languages.) As a concrete goal, I think you should instead pick a small number of distinct domains and advertise as "fits many domains" instead.
"Flexible memory management" is probably the easiest to achieve. Existing languages are surprisingly hard to mix and match multiple memory management schemes primarily because they didn't start with multiple schemes after all. (I believe a GC extension of Rust will be extremely valuable in this regard.) This is something V can directly provide now, keep pursuing it.
"Batteries included" is a cross-cutting concern that touches on almost all other missions except for performance. While this has been one of Python's mottos, it is evident that Python's "batteries" are now too old. Thankfully this issue is also relatively well-understood: you need a good package manager and standard libraries should also use that machinary. Many consider Cargo as the model solution, though not every aspect is appreciated (e.g. single identifier namespace, YMMV). Ironically though Rust itself didn't have Cargo at the beginning, so its standard library situation is not actually ideal. But at least you have a good example to agree or disagree with.
"Readability and development speed of python" is half the anti-simplicity and half the tooling concern. Readability is as subjective as simplicity and development speed has two factors (global and local), where global factor is more about the modularity problem, so let's consider the tooling, the local factor. Tooling is something people like to have and no one likes to appreciate at the same time. It is one of the most labor-intensive tasks in PL and, while you can prepare for them in advance, the actual work needs to be done one by one until approaches like JetBrain MPS become much more viable. It can however happen completely independently from the language development itself as well, so I believe it's of less concern.
The last thing I want to say is that, it's fine to miss all those checkboxes! Many languages are mediocre in all aspects and yet still useful and popular. Some languages even develop a completely unexpected niche out of nothing, like JavaScript and Python. You may still want to retain some good characteristics (which by itself would be an impressive achievement), but you can't know in advance whether they were worthwhile or not. So checkboxes are not as important as they seem---the perseverence to keep them in sight is more important.