nice save

I managed to derive an alternative FILT logic that does the following to increment the number:

The logic is that every bit should only toggle if all previous bits are one. Already I see you use this where for each stage, XOR and AND are used to 'inhibit' a BRAY signal from going through upwards which perhaps enables that bit to be toggled. 

The way I do it is that by default if a bit is to not be toggled (BRAY can pass through), the output BRAY is set to 2^n (where n starts at 'bit 0') and in the following frame has its ctype transferred to the row of XOR at the top. Hence for each bit that should be 'toggled,' its corresponding XOR will not be given a 1 to toggle the appropriate bit. Thus by default one could say that that bit will always be toggling except for 'when it should.'

The fix is that the ctype of the number to be incremented which is passed through this row of XOR is first XORed by 2^28 - 1 or whatever required group of ones in order to flip all of the bits in the operand. Hence all bits that 'aren't supposed to be flipped' get flipped back to what they were while those which are supposed to be flipped as a result of the input XOR 'remain flipped.' Essentially I was hoping this would allow for the use of 28 or 29 bits now as it seems that your method didn't support those extra two bits.

E.g. Where i = input and o = output: For i = 2^29 + B00010011, ctype "toggle row" (collective ctype of all XORs used in toggling the input number) bit n for 0 to 7 = (i XOR (2^(n + 1) - 1) > 0) ? (2^29 + 2^n) : 2^29. Then o = (((i XOR 255) | 2^28) XOR "toggle row") OR 2^29 SUB 2^28. E.g. toggle row (TR) 0 = 0 as always. TR 1 though is also 0 as i XOR 1 = 0. TR 2 is also 1 since i XOR 3 = 0. All other TR bits are 1. Thus !i XOR TR is B11101100 XOR B11111000 which is B00010100 or i + 1.

This design doesn't need to use that ending of alternating ones and zeros which probably prevented it from getting to use the 28th or 29th bits.

I originally intended on expanding on this design so that in the same frame that an input ctype is fed the the counter the incremented result will be output at the bottom or side of the counter with the help of single use PSTN to coax particle IDs on certain pixels. I'm still having trouble achieving that as similar 'current frame result propagation' will be needed to ease the processing of 60 Hz flag register updating and analysis in conditional GOTO operations. 

*Update*: This is what I have right now. id:1842938. The INSL to the left of the DECOed 28 bit capable counter (I've tested it) points at a single piece of METL which with using an up propagating METL/SPRK relay 'y-space below' the circuit can enable that ARAY on a frame to frame basis. If in one frame that METL does not spark, that same frame the current number stored will not be incremented. The instant of the frame where the METL is sparked and the ARAY can be activated that frame, the number will be incremented.

The INSL to the right points to the 'crucial DTEC' where if BRAY for one frame exists at the lower right of it, the counter in that same frame will immediately store it (indicated by the ctype of the green SET FILT to the left of the row of bit toggling XORs) and in the following frame have had incremented it. I will later add a relay to allow for manual input of ctypes and transfers of BRAY to this position.

@FuriousWeasel With the way I did it (placing BRAY with the desired ctype to the lower right of the DTEC at the left of the counter which relays the newly incremented value to the bottom DTEC) there was no 'major latency issue' with loading the counter. It behaved just like my counter in terms of loading. (Note that the BRAY must only occur for one frame. As expected, leaving it to 'die out' will idle the counter at the new value/address but successfully increment upon the frame the BRAY disappears.)

On the other hand, when using the ctype 805,306,367 which contains the number 2^28 - 1 in hope that the counter once incrementing it will reset to zero, I've found that after letting the counter run up to a random number and then performing the 'load in sequence' the counter didn't consistently increment the number sometimes returning erroneous results or taking time to increment this number even after the BRAY has been deleted for a number of frames. So indeed, that affirms what you said about the 28 bit issue, but my design at present will handle increments within that range well.

From various repetitions I'm still not sure if there are any more actual issues with the counter. Otherwise both of our designs or logical implementations work fine.