Actually both seem a bit magical to me.. :-)
There are 105 transactions which all start program SAPMF05A in SAP (FB01, FB02, FB03 etc etc), but they each have their own proposals in SU24 and there is no inheritance.
If the proposals of a transaction is obviously incorrect or incomplete, it should be adjusted in SU24 and not deactivated in each role while keeping an eye on SU53. That is not scalable and looking for trouble with users.
The origin of the field original in the where-used-list is that parameter type transactions (those with an entry in table TSTCP) will pull their own SU24 proposals as usual, but additionally they pull the proposals of the "original" parameterised transaction as well if the parameter transaction does not have a proposal of it's own.
This is for example why all parameter transactions in SPRO using SM30 as "original" to call the view, will propose open fields for S_TABU_DIS until you maintain the correct value for the parameter transaction (which then overrides the "original" from SM30). Also here, deactivating the open proposal of S_TABU_DIS in all roles is not the correct solution.
Cheers,
Julius