AVB implementations can differ between vendors, so a group of manufacturers including RME have focused their efforts on an interoperability standard for audio devices on AVB networks called MILAN. Unfortunately, I have not seen any signs that MOTU plans to modify their AVB implementations for full MILAN compliance, whereas the AVB Tool will be one of the first RME devices to be fully MILAN compliant.

On the contrary, while numerous AVB implementations from various vendors (Apple, AVID, d&B, L'Acoustics, Meyer Sound, Neutrik, to name a few) have changed towards MILAN compliance in the past couple of years, the MOTU devices have not seen a firmware update since May 13th, 2019 and in my own tests, they do not implement a number of features that would be necessary to be fully interoperable. They neither support the mandatory stream formats nor the default AVB maximum transit time, they do not implement counters (for stream statistics and error detection), and several other things.

In general, you will most likely succeed in streaming between MOTU and RME devices (choosing a compatible stream format, 8 Ch. AM824), but you may encounter issues (when re-connecting streams or changing the network while streaming) and RME cannot support those types of issues. It is impossible to test our devices continuously against all AVB implementations out there. So I highly recommend using vendors that state publicly that they are MILAN compliant or at least working towards full MILAN compliance.

There may be a number of forum users that use the combination though, and I welcome everyone to chime in and report their experiences in this thread, especially if it works without problems ;-).

Without knowing details of MOTU's implementation it is hard to answer those questions.

The stream format is not a problem in general, as compatibility can be checked quickly: it either works or doesn't work. RME devices support the stream format that MOTU uses in addition to the newer AAF stream format. This will not be removed anytime soon, even with MILAN certification. And yes, every stream can have a different format (and it can even have its own independent sampling rate).

The issues you'll be facing are more related to the way streams are established in the beginning and how they are monitored. MILAN has a very specific approach to that and it is different from MOTU's approach. I was able, for example, to receive AM824 streams from a MOTU device in a quick test, but MOTU would not receive a stream from the AVB Tool with current firmware (even though it was the same stream format). And as soon as you face issues like that, we can't really help much.

The Digiface AVB has a 'leftover' compatibility mode to provide better support for non-MILAN compliant devices that apparently improves (did a brief test) connections to/from MOTU devices, but that mode applies to all streams (it is a global setting), and then causes MILAN-connections not to function. This mode is not available on the AVB Tool, because it breaks MILAN connectivity and compliance.

The obvious (and probably only) way for manufacturers to be interoperable on AVB networks is to use MILAN (an open subset of the open AVB set of standards). Connecting two MILAN devices will always work no matter what.

For an audio interface like the Digiface AVB, the certification is a bit more complex and this is not currently on our timeline. Think for example about setting the sampling rate over network from an AVB controller while your DAW has requested a specific sampling rate via ASIO/CoreAudio. There are some conflicts of interest where the audio interface has to restrict its configuration options from the network in order not to cause instability in the audio driver architecture of the DAW. But we do test against MILAN devices and make sure that there are no issues that would cause interoperability issues. The Digiface AVB has received numerous firmware and driver updates to extend compatibility in the past year, so generally speaking, it is supported as a MILAN endpoint.

Great! Keep in mind that you also need an AVB switch, such as the Presonus SW5E, in case you don't have one already.

3rd party USB3 chips from ASMedia are known to cause issues. Therefore the RME manual contains information in ch 25.1, that ASMedia USB3 chips are not compatible.

You have two options:
a) to use USB3 ports coming from chipset (AMD or Intel) .. EVERY mainboard has USB3 ports coming from chipset. Use those, consult your mainboards manual.
b) to use an additional PCIe card with e.g. USB3 chips from Fresco Logic (FL1100)

You picked option b) (what I also did) as this gives you the big benefit to fully isolate your recording interface from the rest of the USB infrastructure of your mainboard.

I personally made the experience with my Supermicro Server mainboard that at the beginning the USB3 ports from chipset worked. But then I added more and more USB devices, also USB Bluetooth adapters and then some audio drops startet when using small ASIO buffer sizes.
Such problems were immediately fixed by using a dedicated PCIe card for the recording interface (UFX+) with a supported USB3 chipset.

There can be different reasons why you still might have issues with USB transport errors. USB3 cable length, cable quality, maybe issues with the PCIe slot that you use (maybe shared with other resources). I would consult the manual or ask support which PCIe slot has PCIe lanes coming from the CPU, not from chipset.

What about boards with three USB controllers? According to USBTreeView, only one of mine is ASMedia. (Haven't examined the actual silicon on the PCB).