The order in which the device-tree text file is written, does it matter?

Question

Does the order in which a device-tree text file (.dts) is written matter at all ?

For example, if you take a node from the top of the file and move it to the bottom, wil

Answer 1

Does the order in which the device-tree text file (.dtx) is written matter at all ?

The answer for .dts and .dtsi source files is "depends".
The Device Tree has a structure, so rearrangement of nodes may, or may not, change the system hardware configuration.

---

Overall a Device Tree has a structure such as (slide 23 of Device Tree for Dummies)

/ {
    aliases { ... };
    cpus { ... };
    apb@80000000 {
        apbh@80000000 {
            /* Some devices */
        };
        apbx@80040000 {
            /* Some devices */
        };
    };
    ahb@80080000 {
        /* Some devices */
    };
};

The devices would be described by nodes.
The device nodes attached to a particular bus (e.g. apbh@80000000) could be ordered numerically by device address or alphabetically by device name. This ordering of nodes (within a bus) is not significant.
But if "you take a node from the top of the file and move it to the bottom" and that reassigns the node to a different bus, then obviously you would be defining a different configuration (that's probably incorrect).

---

The file structure of a Device Tree source text is composed of a .dts file (for the board) and optional .dtsi files. Ideally there should be a .dtsi file for the SoC that is generic and can be included by every .dts board file that utilizes that SoC.

The .dtsi file for a SoC is typically provided by the vendor, and should have definitions for all chip devices. Essential devices (e.g. power management, DMA controller) would be defined and enabled. But optional peripheral devices that are not essential and/or those that have I/O connected to multiplexed pins would be disabled.

apbh@80000000 {
    [...]
    hsadc: hsadc@80002000 {
        reg = <0x80002000 0x2000>;
        [...]
        status = "disabled";
    };
    [...]
};

If you want to use an optional peripheral on your board, you should not modify or customize the SoC .dtsi file just for your board.
Rather you should augment that device's node in the top-level board file (which included the SoC .dtsi file), and re-declare the status of the device.

#include "my_soc.dtsi"
/ {
    apb@80000000 {
        apbh@80000000 {

            hsadc: hsadc@80002000 {
                status = "okay";
            };

            [...]
        };
    };
};

To obtain the proper configuration, this node with the status = "okay" has to be positioned after the generic node (in the included .dtsi) so that the status = "disabled" can be overridden.
So clearly this is another case of position dependence.

---

I mean if for example you take a node from the top of the file and move it to the bottom, will it change the order of hardware detection, irq configuration, or whatever ?

The Device Tree is solely for defining the configuration of the system hardware. The execution order of device drivers is controlled by how the drivers are built, i.e. the initcall macros. See init function invocation of drivers compiled into kernel and What is the difference between module_init and subsys_initcall while initializing the driver?
The acquisition of resources by a device driver is under control of that driver, and not directed by the Device Tree properties, which are merely read by the driver.