What is "Orthogonality"?

Real life examples of orthogonality in programming languages

There are a lot of answers already that explain what orthogonality generally is while specifying some made up examples. E.g. this answer explains it well. I wanted to provide (and gather) some real life examples of orthogonal or non-orthogonal features in programming languages:

Orthogonal: C++20 Modules and Namespaces

On the cppreference-page about the new Modules system in c++20 is written:

Modules are orthogonal to namespaces

In this case they write that modules are orthogonal to namespaces because a statement like import foo will not import the module-namespace related to foo:

import foo;            // foo exports foo::bar()
bar ();                // Error
foo::bar ();           // Ok
using namespace foo;
bar ();                // Ok

(adapted from modules-cppcon2017 slide 9)

In programming languages a programming language feature is said to be orthogonal if it is bounded with no restrictions (or exceptions). For example, in Pascal functions can't return structured types. This is a restriction on returning values from a function. Therefore we it is considered as a non-orthogonal feature. ;)

The basic idea of orthogonality is that things that are not related conceptually should not be related in the system. Parts of the architecture that really have nothing to do with the other, such as the database and the UI, should not need to be changed together. A change to one should not cause a change to the other.

Orthogonality is the idea that things that are not related conceptually should not be related in the system so parts of the architecture that have nothing to do with each other, like the database and UI should not be changed together. A change to one part of your system should not cause the change to the other.

If for example, you change a few lines on the screen and cause a change in the database schema, this is called coupling. You usually want to minimize coupling between things that are mostly unrelated because it can grow and the system can become a nightmare to maintain in the long run.

From Michael C. Feathers' book "Working Effectively With Legacy Code":

If you want to change existing behavior in your code and there is exactly one place you have to go to make that change, you've got orthogonality.