I think it makes sense to design a language considering the capabilities of an IDE. I suppose that is like what we have already in essence, except maybe without a capital I, as our languages are based on the keyboard, and ascii characters, and so forth. We write programs with text, and there is assumed to be some kind of text editor and interpreter or compiler. That all is essentially a development environment.
Keyboards are pretty archaic and languages we use now are pretty much designed around their limitations. I've commonly wondered why we haven't designed a specialized version of the keyboard for programming specifically, since we could expand the sets of characters/symbols, and even include keys that can generate common compound statements or snippets. If the keyboard itself was different, then we would have designed the languages differently.
In general, we have not really experimented deeply how we might interface with an "editor" or ide, or what form the language of that interface is in. What do we use in a VR or AR environment?
You could build in accessibility translations, like voice to text, but customized and standardized for coding. And print to sound.
Maybe it could build in debugging functionalities, like adding breakpoints in the language itself.
Beyond the basic interface, you can include a standardized metalanguage to interact with the ide. Well this kind of exists, in C or C++ for example, people can use #pragma to interact with the IDE or preprocessor and compiler (e.g. to disable warnings for some code block, or compile the block of code in some special way), or interact with the preprocessor in other ways using macros, template meta programming, etc.
Boiler plate code can be dealt with by copying and pasting, but also by abstraction, modularity and the DRY principle. Languages already have built in capabilities to do that. These things often are so custom and the range of possibilities are so vast that it's perhaps sometimes better to do these things programmatically.
Sublime text as an example, is programmatically customizable so that you can design your own snippets, tab completion logic, trigger arbitrary preprocessing, etc. But I never like using snippets because they usually leave too many fill in the blanks, which interrupt the flow.
Another thing we have is regular expressions, which are useful in an IDE for find and replace etc. In some ide's you can also process the text with built in refactoring tools for smarter text replacement etc.
In general, we want to better manage complexity. The issue is that complexity is not a unitary thing. On the one hand you have something like Shannon entropy, how verbose the code needs to be, and on the other hand you have complexity in terms of the simplicity of organization and parameterization. And there is a tradeoff ; you make a simple but verbose and low level language and you don't need a long instruction manual (i.e. C, which doesn't takes long to learn) or you have complex features exposing more generalization and organizational complexity and you need a long instruction manual (i.e. C++, especially metaprogramming, and "concepts", which takes a long time and thousands of page of information to fully understand. So there is a Pareto optimization to do here when designing a language so that complexity is manageable and the code is understandable and maintainable.
The development environment is definitely a part of complexity management, so it makes sense to at least consider it when making these tradeoffs. For example, Java with Eclipse has the hotkey to show documentation feature, and I guess you can expect that all of the Java libraries have documentation. And there is some kind of standardization to the way it's documented so that users can easily navigate the documentation on demand. This is enormously helpful for ameliorating the burden of second kind of complexity (long instruction manual). You also have similar features in other IDEs and somewhat standard tools like doxygen. These are examples of embedded metalanguages that talk to the IDE I guess.
In general, it's these higher order IDE features which tend to make those higher level more abstracted and generic language features more usable.
I mentioned the DRY principle. Which means don't repeat yourself. E.g. try to eliminate redundancy and unnecessary verbosity. This is achieved through higher level features, for example with generics. But the issue is you commonly will have many slightly different versions if the same thing. So generalizing in programming language constructs can be complex (lots of degrees of freedoms for an abstract object, long instruction manual). But IDEs can he capable of detecting code reusability and exposing those degrees of freedom interactively in an easier way. Or different ways of doing it manually, through abstraction layers embedded in an ide could be possible. So I imagine new possibilities for dealing with DRYness if the language and the IDE talk to each other.
Multilevel languages, using DSLs at different layers, are also possible (e.g. like html css and javascript), except where some layer handles talking with the IDE specifically.