Hello Laurent,
First - RME's implementation of clocking from Madi works very well, used it for many years on many devices. Best in the business actually and we use a LOT of Madi devices.
Could I say that my local ADAT device and the Octamic are strictly sync'ed as if they would have been if they were both connected to an external common WordClock signal (or if MADI were a real self-clocking signal)?
I recognize clocking can be confusing until you master it but if I interpret your questioning correctly - all good questions incidentally if you're trying to understand - your issue is confusing how the clock must appear to and between devices.
Short version - accurate to a first order of approximation - clocking does not need to be exactly temporally synchronous between devices, but it must be at exactly the same rate between devices.
Long version -
Generally the rising edge of a wc signal is considered the start of an audio timing frame whether it's AES, adat, Madi, video blackburst, or whatever, so let's call that our zero time reference. From that simple 48k sample clock (which started out as an I2S bus, high=left channel, low=right channel) the device being clocked uses a PLL to derive a 256x or 512x internal clock, called an mclk, that is the actual internal audio clock within the device. The PLL constantly compares that inbound 48k slightly jittery word clock with it's own internal mclk (that's the definition of a PLL) and makes small adjustments to make sure the internal mclk is accurate to the inbound clock. This mclk is used to drive the A/Ds, D/As, and other audio clocks (I'm leaving out FPGAs, this is a simplification). The PLL is the basic topology block, RME's SteadyClock is an extremely good hardware and software implementation of the concept.
As soon as you feed a wc signal to a device you have introduced jitter, indeed sending signals across the circuit board induces jitter. Can be very small jitter, can be huge jitter. So already in every device there's not a correlation between the exact timing of the zero timing reference between devices, the inbound PLL must convert the wc signal into the mclk plus LRclk and that takes time. Some devices may use the PLL to approximate the zero timing reference to match the inbound, some don't, but it doesn't matter. As long as the clocks are moving at exactly the same rate the clocking will be fine between the devices.
Imagine a wc signal locally and at the end of a -really- long piece of fiber. The clock master's internal LRclk and mclk are driving it's local conversion. The conversion to fiber plus the long piece of fiber plus the conversion to copper wc into the device creates a delay between the zero ref of the clock master and the zero ref of the remotely driven device. It does not matter - as long as the rate is exactly the same between devices the phase (not talking about polarity!) between the clocks does not matter. The remote clock can be offset any amount in phase, plus the returning audio takes some time which creates further phase offsets, but as long as it's speed is accurate the clocking will work. Zero time is not zero time anywhere except within a device (and even then there are delays... just saying).
So back to Madi. Madi is not defined as a synchronous signal. However SteadyClock can make a good reliable clock of inbound Madi and it does so quite well. Every good quality device as a general rule will -technically- work most accurately on it's internal clock since it's not doing PLL adjustments from a low frequency inbound, and every device has varying degrees of accuracy when clocked externally. Is there an audible difference? Sure in theory - if a device does not have a fantastic PLL on the input then clocking externally will sound different than clocking internally. With good quality devices you generally can't hear the difference. There are many conspiracy theories around external/internal clocking so that's not the discussion, the take-away is you use the best clocking scheme for your application. Fortunately for RME SteadyClock if the clocking between devices is reliable and reasonably low jitter it will sound the same no matter how it's clocked. Not all devices operate as painlessly.
I hope this helps, the summation is - clocking delay doesn't matter. Clocking speed does.
Hugh
