BS 7671 doesn't really take this installation method into account in Appendix 4, as it only goes up to 6 buried circuits, AND 4C3 only covers 1 multicore cable per duct. You may have to adopt another approach following relevant parts of BS IEC 60287 series, or following ERA guidance.

It might be reasonable to apply grouping to the cables sharing a duct as if they were touching, and then apply grouping to the ducts per Table 4C3 ... but things might get a little "over-engineered" (much larger cable sizes). You'd have to assume the ducts could affect each other , as whilst opposite corners are further away, with only 100 mm separation, they're likely all to be within the 0.25 m of each other.

Whichever method you choose, also leaves the question of what you might assume for the spare duct (given it's a spare, some assumption ought to be made regards its potential use, otherwise if you size the cables right to the max, it's no longer spare as it can't be used without overheating the cables in the 3 used ducts we are thinking about).

All of this perhaps meaning cable sizes double (or more) just on grouping alone ?

The degree of cooling will also depend on the length of the duct and how much free flow of air you expect to have although as the run gets longer, that effect gets less significant , and if you expect the ground  to be wet or not( and I suppose  if the ducts end up being full of water - in some installations they can be)

If they were much further apart - a few duct diameters, they would  be considered completely thermally independent, but in this case they are weakly coupled, but nothing like as strongly coupled as they would be if all cabling was in one (bigger) duct.

As has already been mentioned this weakly coupled case is not one covered in the standard tables and either assuming one large group (oversizing), or some intelligent interpolation between the one duct and the widely spaced ducts case will be needed. The problem is that to do this almost certainly needs information you do not have.

Mike.

@gkenyon and @mapj1, thank you for your responses. I can also see now this is not as simple as first thought.