Quoting Miroslav Skoric (skoric@???):

> Possibly ... but you need to explain that to the 3rd party software
> programmers. All I have remembered to be compiled from sources
> locally, went to /usr/local/.. Seems as (un)written consensus;
> however nobody suggested to have /usr/local/ as a separate partition
> at install.

Nobody _you_ heard, perhaps, but it's routinely done by us server admins,
as there are compelling advantages, e.g., with /usr/local being distinct
from /usr, you can have different sets of mount options. Here's how I
designed /etc/fstab on a typical server I constructed in the middle
2000s:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

## sda is (obviously) the boot drive.  73 GB SCSI.
/dev/sda1       /boot           ext2    defaults        0       2
/dev/sda5       none            swap    sw              0       0
/dev/sda6       /var            ext2    noatime,nodev,nosuid 0       2
/dev/sda7       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda8       /recovery       ext3    defaults        0       2
/dev/sda9       /usr            ext2    nodev,ro        0       2

## sdb and sdc are RAID1 mirrored, except for swap.  Each is 18 GB SCSI.
/dev/md0        /var/www        ext3    nodev,nosuid    0       2   #sdb5,sdc5
/dev/md1        /var/lib        ext3    nodev           0       2   #sdb6,sdc6
/dev/md2        /var/spool      ext3    defaults        0       2   #sdb7,sdc7
/dev/sdb8       none            swap    sw              0       0
/dev/sdc8       none            swap    sw              0       0
/dev/md3        /home           ext3    defaults        0       2   #sdb9,sbc9
/dev/md4        /usr/local      ext3    defaults        0       2   #sdb10,sdc10

These days, I would do it quite differently, especially on account of
using SSDs instead of hard drives, so, e.g., there's no need to group
filesystems to minimise average seek distance/time on an SSD that
inherently doesn't need to perform seek operations in the first place.
However, as a detail of the above, notice that /usr is normally mounted
read-only, while /usr/local is not. This different requires that they
be distinct filesystems. (/usr is also ext2 in this example, as there's
no advantage to the overhead of journaling on a filesystem left normally
read-only.)

In case people are wondering, details of how to keep /usr mounted
read-only and still let apt work correctly without manual intervention
can be found here:
http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00212.html

Having /usr normally unmounted is an example of routine caution
against likely failure modes: That filesystem is where almost all
system programs and libs live, and on a typical Linux system is (at
least by default and initially) where most of its complexity and disk
usage is. It is a tree you as local system administrator wish to
protect against mishap. The most likely source of such mishap is:
you, the local system administrator.

I have /usr normally unmounted in order to have in place a first-level
default protection against the worst threat to its orderly management
and contents, i.e., against myself. If I am careless with the root-user
account and launch a recursive chown of something that would cascade
down /usr, for example, it will (by design) fail.

Pretty much the only time /usr needs to be mounted read-write is during
package operations. For that exact reason, I have a pair of scripts
invoked via dpkg hooks (see debian-devel link, above) that remount /usr
read-write just before packages get installed or removed, and then
remount it read-only again immediately when the package operations are
done.