@ legacy
Potremmo discutere per ore, rimanendo ognuno sulle proprie posizioni. Le nostre sono due soluzioni legate a due concetti diversi ed in parte divergenti. Il mondo è bello perché è vario 
Venendo ai tuoi commenti:
Il costo non è solo quello del nodo in se (maggiore di 20 euro), ma il costo degli alimentatori e dell'alimentazione, il maggiore spazio richiesto. Ho sempre creduto nel "quello che non c'è non si rompe" e l'idea di distribuire i compiti tra i nodi è uno degli aspetti principali del progetto.
Suddividere il codice in librerie è già un modo per "imperare", se poi girano su un unico nodo o su nodi diversi, se fatto bene non cambia nulla. Anche io sviluppo il codice da solo, in tempi relativamente lunghi (il progetto è parito a Maggio del 2010) dedicandoci qualche ora la sera. Ultimamente ho ricevuto delle proposte di collaborazione per la parte di interfaccia
Se consideriamo la funzionalità di un publish/subscribing, gli eventi difficilmente si sovrappongono ed è per questo che uso questa funzionalità in MaCaco :), ma ricorda che sottovalutare Murphy è il primo passo verso il baratro
L'implementazione parziale del TCP/IP di cui si parlava, era relativa al supporto alla frammentazione dei pacchetti e non all'algoritmo che regola l'occupazione della banda. Tra le righe il W5100 non supporta la frammentazione dei pacchetti (se non ricordo male). Quindi il problema non si pone.
Ritornando al protcollo MaCaco, utilizzare un protocollo derivato e non il Modbus è legato ai motivi già discussi, come tutte le decisioni ha dei pregi e dei vantaggi. Personalmente, non intendo introdurre una compatibilità verso prodotti commerciali.
La compatibilità verso prodotti commerciali proprietari ha senso se si sta progettando prodotto competitiore low cost, ma per un progetto Open Source non ne vedo l'utilità. Inoltre i costi necessari per testare ciò sarebbero fuori dalla mia portata.
Leggendo alcune tue considerazioni, come costo orario e retrocompatibilità, sembra che tu stia lavorando ad un progetto proprietario da immettere sul mercato. In quel caso, utilizzare un numero maggiore di nodi hardware ha un vantaggio diretto in termini di danari, ma è il motivo (a mio avviso) per cui i prodotti commerciali hanno un nodo per il clock, un nodo per gli scenari, un nodo per ogni cosa...
Relativamente a vNet, è un modo per avere tre funzionalità: astrazione, routing e bridging. Queste sono fornite a livello IP, ma non ho intenzione di sviluppare IP su un nodo, quindi uso una soluzione diversa con diverse analogie con IP. Questo mi garantisce delle funzionalità di base anche su interfacce MAC.
Detto questo, spero che da questa discussione nasca la possibilità di migliorare lo sviluppo del mio codice, basandomi su quanto da te fatto e viceversa. Ma tranquillo, non prenderò Apache!
Saluti,
Dario.