Si il circuito di prova ha i suoi limiti, è evidente.
Per quanto riguarda il sincronismo ho avuto lo stesso dubbio ed in effetti nel funzionamento reale concordo che possa essere la radice del problema.
Potresti provare ad usare il port change interrupt per sincronizzare i due circuiti invece di fare lo scan in loop.
L'unico svantaggio è che il mega lo supporta solo su alcuni pin specifici e quindi dovresti ricablare il circuito.
Ricablare non è un problema, grazie! Farò varie prove e vi farò sapere 
Non è mai buona cosa scansionare una matrice già in scansione da un altro oggetto
ho fatto delle ipotesi, sulla base delle quali ho poi fatto delle congetture
ipotesi:
Il dartboard scandisce la matrice tenendo normalmente alte le uscite, e abbassando di volta in volta l'uscita in scansione (ragionevole, dato che arduini legge il !pin)
Ipotesi
Il datboard alimenta le colonne (ragionevole: la lettura è mediamente più alta che bassa 4.2V)
e legge le righe (ragionevole, le righe sono mediamente a valore basso, se fossero loro alimentate sarebbero alte)
Ipotesi zero: quella sottostante a tutto:
le letture citate sono ottenute con un multimetro che integra fortemente (a lancetta o rms) la conferma sarebbe da ottenere con un oscilloscopio, ma non andiamo troppo oltre
avanti adesso con le congetture
congettura:
data forte differenza di velocità tra arduino (che oltretutto presume alimentate le righe e non le colonne) il ciclo interno (lettura righe) riesce a leggere due o più input successivi, che non corrispondono a due o più pulsanti premuti, ma alle successive uscite attivate dal dartboard durante la sua scansione
soluzione?
ammesso e non provato che Arduino abbia una velocità sufficente, dopo aber snellito il programma di ogni orpello inutile (debounce sopratutto)
si tratta di leggere prima le righe (ciclo esterno) e solo nel ciclo interno le colonne
per riuscire a tenerle sincronizzate vedo come unica possibilità, dopo aver percorso il ciclo interno aggiungere un while(input(riga)) a vuoto, che bruci un tempo sufficente a tener fermo l'arduino prima che il Dartboard cambi riga
sempre ammesso che Arduino sia più veloce del Dartboard
altrimenti è impossibile risolvere
la cosa tra l'altro non richiede nemmeno un interrupt change
Giusto
Spiegherebbe tutto
Mi sa che ci hai pigliato
Peraltro che eri bravo lo sapevo
ho fatto tutte le prove che mi avete consigliato ma non sono andate a buon fine, penso abbia ragione @C1P8 . Guardando il datasheet del mcu del dartboard ho raccolto informazioni sul funzionamento della matrice, Utilizza i segmenti sia per il display LCD che per la scansione della matrice stessa (sicuramente i pin da pa0 a pa6 sono le colonne, che includono anche i due contatti di accensione e start rintracciati dal monitor seriale dato che la matrice è da 84 -7x12, il pannello dart ne richiede 82). possiede un cristallo a 32768Hz che presumo sia anche la frequenza di scansione. l'ultima soluzione che potrei tentare sarebbe cercare di sincronizzare quel cristallo con arduino ma questo non so se sia fattibile
Ripartiamo da capo che di prima mattina non ci sono in pieno
La sincronia:
Te lo hanno spiegato come fare, lo hai fatto?
Tra le altre cose sarebbe anche facile da fare
Il quarzo:
Lascia stare, è un'idea balorda
Start e stop:
Dove come e quando li hai trovati nella seriale?
Spiega bene, e se ci sono alte cose che non ci hai detto dille
Le prove che hai fatto e non hanno sortito
Falle vedere e spiega cosa succedeva
È così che si impara
Guardacaso anch'io lo penso 
Comunque andiamo avanti
Ignora tutto quello che non riguarda la matrice di pulsanti
Non devi sincronizzare il cristallo, ma la scansione
E ti ho spiegato come fare
Mostrami le prove che hai fatto
I tasti power e start li ho rintracciati sulla matrice perché premendoli me li segnava su r6 c2 ed r6 c3 (che quasi sicuramente saranno su un altra riga dato che per il momento mi vede solo r6, solo quei due tasti, gli altri non sono sulla matrice.
Verso sera ti aggiorno su tutto, grazie per l'aiuto!
Ritorno alla carica con il simulatore 
Per cercare di rendere la cosa un po' più realistica, ho usato un ESP32 cosi da avere il supporto per FreeRTOS in modo da poter avviare un task che gira in parallelo al loop() principale con l'unico scopo di impostare a LOW le righe delle matrici.
I pin che vanno a LOW non sono gli stessi che vengono letti dall'algoritmo cosi da non interferire con la scansione principale e simulare l'azione "esterna" della dartboard.
Se non ho capito male, dicevi di fare qualcosa del genere per velocizzare la scansione dell'Arduino? La scansione esterna delle righe è abbastanza lenta (1ms).
Sarebbe utile avere qualche informazione in più da @anon89157771... l'ideale sarebbe il tracing di un oscilloscopio.
Ho mantenuto parte della logica di debounce che aveva implementato @anon89157771 anche se non funziona granché.
Secondo me sarebbe da gestire il fronte del segnale, anche perché se la freccia rimane attaccata alla board il contatto rimane chiuso o sbaglio?
Quando viene colpito il bersaglio il contatto non rimane chiuso
Comunque verso sera carico il codice che ho utilizzato per le prove che è senza debounce quindi mi segna le righe "a raffica"
ma quello non è un problema, dimostra solo che il contatto "rimane chiuso" per un certo tempo,
normale essendo il contatto meccanico, quindi lento rispetto all'elettronica
Secondo me più che rimbalzi del segnale si tratta proprio del fatto che il loop() di Arduino è molto più veloce della durata del singolo impulso e quindi per ogni freccia messa a segno viene eseguita la scansione più volte per lo stesso evento.
Un possibile approccio, come dicevo, potrebbe essere quello del fronte con un reset temporizzato degli stati memorizzati per consentire la lettura consecutiva sullo stesso segmento della board. Il tempo di reset dovrebbe essere leggermente maggiore della durata del singolo impulso.
Ho aggiornato l'esempio wokwi secondo questa logica e nel mondo simulato sembra funzionare bene 
Ok che hai simulato l'azione in parallelo ma non hai tenuto conto che l'mcu del dartboard scansiona continuamente le righe, è questo il problema...
Purtroppo mi hanno dato conferma che ciò che avevo intenzione di fare non è fattibile.
Se vuoi carico anche tutti i codici a cui ho lavorato con i consigli che mi avete dato ma sono inutilizzabili per lo scopo. Ho provato sia con che senza resistenze di limitazione corrente, con e senza pullup interne/esterne, con le pulldown e logica invertita... Niente da fare.
L'unica soluzione è escludere l'elettronica del dartboard e usare il progetto opendarts... O tentare lo sniffing della sram (non ci provo nemmeno)
Grazie comunque a tutti per i consigli e mi dispiace avervi fatto perdere tempo
Guarda che lo sketch di esempio che ho messo, fa esattamente la stessa cosa usando il task FreeRTOS "scanTask" che viene eseguito in parallelo al ciclo loop().
L'ultima prova posso anche farla, sempre se è fattibile implementarlo nel mega
Non hai bisogno di FreeRTOS sul mega, quello era solo per simulare in qualche modo la tua situazione.
direi che dopo tutto lo sforzo che abbiamo fatto sia il minimo da parte tua
certo: hai fatto tutte le prove che NON servivano e infatti non hai ottenuto il risultato
adesso che ti sei fatto del male da solo cominci a fare le prove che servono oppure lasci stare?
quella che ti ho detto io: sincronizzare le letture dei piedini aspettando con un while che la dartboard passi alla scansione successiva
certo che se non ha voglia di farlo...
L'ho fatto, te l'ho detto ieri... Tra poco preparo uno zip con i vari codici e lo carico
Ho dato uno sguardo ai programmi che hai postato
credo che non ci siamo
Passo 1: codice 2 da testare.txt
Ti ho ben detto chiaro che qui è questione di guadagnare la massima velocità per garantire che una scansione di arduino fosse certamente più veloce di una scansione della dartboard, ma tu mi metti addirittura delle print nella scansione...
oltretutto non potevi metterlo in chiaro? oppure credi che il "mio" tempo possa essere speso a scaricare i "tuoi" file?
passo 2: dartboardmegatest
peggio che peggio, qui leggi le righe alte e le colonne basse, dopo averle aperte tutte e due input_pullup
bisogna che ti fermi a pensare di più a cosa stai scrivendo
Passo 3: oggi1.txt
e non ci siamo ancora: ma io ti ho detto come sincronizzare le due scansioni, e ancora non lo hai fatto, non ci siamo proprio
comunque voglio credere che per buona volontà tu abbia messo tutte le prove, anche quelle palesemente sbagliate come questa
ma io non ho voglia di mettermi a scaricare una decina di file per capire qul'è quello che mi interessa, capiscimi a me: ho anche altre cose da fare nella vita..
cortesemente mi metti qui in chiaro e ben indentato il programma che hai usato per provare il mio suggerimento, grazie
