no leo, vorrei analizzare meglio la situazione.
Se il watchdog lancia una funzione, che retta il watchdog e poi fa qualcosa. se dura più del prossimo interrupt watchdog, che non si resetta, mi aspetto che la funzione venga lanciata di nuovo, bloccando temporaneamente le prima esecuzione. Ovviamente se ci sono variabili globali (e se usi librerie tipo Serial, Wire, etc..) in uso nasce un casino della madonna, perchè potresti usare valori temporanei.
In oltre ogni richiamo è una chiamata a funzione in stack, il che può causare uno stack overflow. Notare che comunque la seconda chiama riazzera il watchdog, quindi nessun problema di restet
il problema sussiste se invece il secondo interrupt viene ignorato perchè la ISR è già in esecuzione. In tal caso hai ragione a eliminare il reset, ma sinceramente cercherei una soluzione migliore, per esempio forzare il richiamo della ISR, ma una variabile ti avvisa se c'è qualche funzione pendente in esecuzione. In tal caso resetti il timer ma NON lanci l'esecuzione del nuovo codice. Potresti usare un puntatore a funzione al posto della variabile, se è NULL allora fai partire la funzione richiesta, se non è null e la funzione schedulata è differente da quella in esecuzione (e in modalità DEBUG), allora lanci un alert per avvisare l'utente del ritardi di esecuzione del task a causa della sua funzione precedente troppo pesante, o perchè ha schedulato due task per avvenire assieme.
Seguendo questo principio della modalità DEBUG, puoi avvisare l'utente quando stai effettivamente lanciando una sua funzione, calcolando anche l'errore rispetto all'orario impostato.
bhe direi che per ora ti ho rotto le balle abbastanza 