> Can you specify?

A few examples:

Datatypes lets most newer Amiga programs load any type of file of a format that people have written datatype libraries for. E.g. all image viewers and editors that supports datatypes (pretty much all the were still under development when datatypes where introduced) can load pretty much any image format you can think of without any explicit application support as people are still writing them. Datatypes support also exists for e.g. music, word processing documents and others. For some applications it makes sense to have their own custom filters for some formats, but datatypes provides a minimum level of support for even obscure formats, as well as continued support for new formats for applications that are no longer in development.

Similarly any app that supports XPK can transparently decompress and compress any compression format you drop a library for into the right directory (and in fact there's a XPK datatype, that if installed lets any application that supports another datatype - such as for images, or documents - support compressed versions of the same).

Assigns is one of my favorites: Amiga applications typically load libraries from "libs:". "Libs:" is a virtual directory that is the union of a set of paths that typically includes "progdir:libs/" (but doesn't have to). "progdir:" again is a virtual directory that refers to the directory the application is installed in. It's somewhat like $PATH, except you can create your own assigns, and lookups are handled at OS level. You can somewhat simulate it on Linux with combinations of various obscure filesystem drivers, but there's nothing like the ease of use of assigns. Assigns are also given special treatment in filesystem dialogs/requesters, which meant that e.g. having a "docs:" and "pics:" assign or similar was common ways of creating shortcuts to the stuff you used the most, without needing any explicit support anywhere.

And these names also extends to volumes/labels of physical media. Think backup application that knows the label of the DVD you burned file X to. Want to restore it? Backup application could ask you to insert DVD labelled "August 2014", or on AmigaOS it would just try to open the file "August2014:X" and AmigaOS will ask you to please insert volume "August2014" with no application support needed. This is admittedly a feature that was far more important when dealing with physical media was more common.

OS support for running controls/widgets (gadgets in AmigaOS) in separate threads ensures a high degree of responsiveness even when the machine is under high load.

Ease of writing filesystem drivers means you find stuff like FrexxEd - a text editor that exposes the open buffers as files, so that you can operate on the open buffers with any tools that can process a file.

Pervasive AREXX support meant pretty much every application can be fully scripted, either "natively" in AREXX, or from pretty much every language by talking to the applications AREXX port.

> what lessons are you talking about?

Decomposing applications and treating the system as a whole, for starters. For AmigaOS this was an absolute necessity: You wouldn't have the space to effectively multitask on a machine with 512KB RAM if everyone needed to pull in huge amounts of different dependencies. So there was a lot more effort into standard components, or replacements for standard components, that allowed applications to do more with very little.

Not being wasteful, certainly. Above I mentioned FrexxEd. The custom filesystem in FrexxEd might seem like unnecessary bloat. But on a small system it meant that you did not have to write to a temporary file in T: which would commonly be assigned to RAM:T/ which would mean you'd suddenly have a second copy of the file in memory, instead of just processing what was already there. Similarly, the way cut and paste is implemented in AmigaOS is intended to be able to deal with efficient buffering to T: in case it has been re-assigned to a slow device (even a harddrive would have been slow enough to make the UI sluggish if you were to cut and paste a large chunk of data).

But the things that made these applications work well on such small machines also makes them blazingly fast on modern machines where UI's are somehow still sluggish even when they don't add much functionality (it's another matter if a super-complex UI is slow)