NOTE, we 'could' add a limited alias abliilty, at least within the dynamic, and I think I probably 'could' get that solid.  That is only part of the alias problem, but it is a significant part of it.  I know that @magnumripper had me 'hide' some of the dynamic formats recently (the text book and self testing formats).  While I am not too keen for doing that, since I think it describes for users just what 'can' be done, and if users do not see that, then they do not know how/what can be done within dyna.  But one other complaint @magnumripper was that there are many dupes in dyna. Yes, there are formats that 'can' process the same hashes, and there are some dupes.  But there are also some 2-class formats. One that is quicker but limited to a 55 byte input limb on SIMD, and one that is a little slower, but users FLAT buffer SIMD so does not have unreasonable length limits.

I could see adding dynamic only aliasing as a phase-1   I originally thought alias code would be a smaller undertaking. It is not.  It 'really' needs to have core changes to have a couple methods added to the formats to 'help'.  But instead of doing this like this, or like I was doing (which was piece meal ad-hoc), we really should address this in a an engineering design way, by asking what we have, and what we need to get the job done.  (SORRY for long rant, it should be done on some other thread).