There are often multiple choices when we are looking for a software tool to do <something&gt;. Some of the possible softwares may be quite archaic, have been around for decades and were used for many different tasks and in many projects throughout their lifetime. Others may be the latest newcomers, have not even hit version 1.0 yet, are built on top of brand new frameworks, libraries and APIs, and come with a modern look-and-feel.

Of course we always want the latest features which make our lives easier and our coding more productive.

On the other hand our code should remain portable among tool chains and vendors, so we are able to migrate easily (many reasons for why this could become necessary).

Following the first guideline will always restrict us to the minimum feature set offered by all vendors in question. Even if some vendors already support a certain feature it can not be used for compatibility reasons if another vendor does not support it yet. That’s because doing so could prevent migration to this vendor at a later point. Hoping that by then this feature will be supported everywhere is not an viable option.

In practice the decision is mostly made on a case-by-case basis, considering the value of a new feature against the danger of portability issues.