If I get that right, you propose to drop everything besides the actual name from the FactName. How we’d keep the hierarchy then? Or do you propose to flatten this entirely and stop storing the parent links? I guess that’s what you mean by the “stored architecture of facts”?
I think this is in fact pretty common use case. People use Puppet and Ansible for two different purposes. Also there are subscription-manager facts that are sent from registered hosts every 4 hours and report similar data as Puppet or Ansible. I think we should be considering multiple fact sources as a valid or even common use case.
Ad idea 1 - so you say to have a single general importer, while we keep parser for each origin separate, correct? I’d 
to that.
Ad idea 2 - I’d be against adding another DB just to store the JSON. But the actual proposal here is to implement Arbitraty facts as defined in the common facts RFC?
Ad idea 3 - Puppet specifically has a feature (or quirk) that the ENC can be generated based on the facts. Therefore facts processing must happen before the ENC is rendered and therefore the enc.rb script waits for the request to finish first. It could still be implemented even if the facts processing is asynchronous but we never added polling to the enc.rb. I think having facts parsing as a background task is generally a good thing to have and other than Puppet facts can already use foreman-tasks for that. I think it’s time to make this the only way and see if there’s someone who actually relies on this. If so, we’d need to adjust enc.rb and add the polling in there. In general from me.