LBMs are a technical feature used internally by Minetest mods. They're covered, to some extent, by the following file in the MT git tree:
There is additional documentation in the Trolltest wiki which will be merged here in due course.
This page provides supplemental remarks.
An LBM, or Loading Block Modifier, is a subroutine that typically converts one type of node to another or makes some adjustment to nodes.
LBMs can be set up to run just once per mapblock or on each mapblock each time that the mapblock is loaded.
I don't advise the first mode of operation. Most importantly, it requires additional disk storage. Additionally, it complicates cases where LBMs are modified or maps are edited using CoderEdit schems or MineSplice.
ABMs don't have these issues but introduce a load at runtime because they run, in effect, continuously.
The second LBM mode, run on every load, is a reasonable compromise. It's less problematic than the first LBM mode but lighter than the ABM approach.
As a bonus, the second LBM mode is nearly interchangeable, at the code level, with the ABM approach.
If an LBM is written correctly, a world developer can switch back and forth between the two approaches simply by changing one letter in the source code.
Future: Insert examples here.
Future: Document the new routine default.convert_node which registers a node to be converted with an internal LBM node conversion feature.
Maps may contain nodes that aren't defined by the current _game. The primary use case for LBMs is conversion of such nodes to supported types.
Minetest aliases are a possible alternative. They're very simple to write and don't impose much of a CPU penalty at runtime. LBMs are complex in comparison.
In practice, the use of aliases is very common. If over-done, however, it leads to complex situations that can be difficult to debug or untangle.
Legacy code accumulates and _games end up with aliases of aliases. In some cases, there are conflicts or other problems.
Additionally, aliases take up room in data structures and large numbers may theoretically impact performance.
A properly written LBM converts nodes at a single clear and specific point in the code. In "run at every load" mode, no significant data storage should be required.
And, after a map has been completely loaded, you're done. Depending on the situation, you may be able to disable or remove the LBM if this is desired.
OTOH aliases are so common that it would be problematic to replace them all with LBMs.
The position of Final MT is that LBMs and aliases both have their places.