What was proposed and discussed is a different thing, and it isn't something which can be achieved writings a few lines of code, even using Python (which is particularly well suited for most of the needed tasks, since it has built-in libraries and requires much less lines of code compared to other languages).
Of course you might have made a proposal (and which isn't a bad one) which works differently from what is currently implemented but ..., why bother ?
right now:
- obtain data from system
- share data obtained from system
what you seem to propose:
- obtain data from system
- present user with information on already obtained system data from a "huge" database and check their specific system data against it (is it supported or not)
- share data obtained from system
That looks/smells to me as a natural evolution of code that is already in place. Might perhaps be working differently as proposed but as long as the results are the same.
Indeed. As I've said before, the existing part might be a starting point for this new feature.
The fact is that current implementation never matured because Paolone indicated back then that it was hardly used (only 2/3 people bothered, but please correct me if wrong).
In this case the new tool might be executed transparently the first time that Icaros runs (just after the installation).
If all peripherals found are supported then no action is taken.
If some is not found on the database, then a report is shown to the user with the current status of its machine, and asking to send the feedback (with some togglebutton which can be used to indicate if the specific peripheral is working fine, not working, or if its status is unknown. Unknown is the default status).
As you wrote yourself python having a good stack of libraries, i base my opinion on a good stack of subroutines that i (or anyone else with some decent programming skills) can take a pick from, and make use of the current infrastructure that is in place.
Python is a great tool which allows to more quickly fill the gaps in many areas. In fact, it's already used on many Linux / BSD or other o.ses a system tool.
The primary problem with AROS is that it's missing (the one which runs is really too much outdated). So, porting a new version (3.9 is the last one, which I recommend).
The second, and not even less important, is that if you decide to integrate Python as a system tool, then you can say goodbye to the original Amiga machines, even if expanded, because it requires way much more resources. I don't care so much, because today we have TONs of resources even on very low-end machines (e.g.: Raspberry Pi. Which was built around Python, BTW), but some people might be upset. This is a decision which AROS devs have to take (once Python is finally ported, of course).
But for tools like the ones which we're talking, using Python just server-side isn't a problem. It's already there: only need to be used.
Based on that then yes the discussion on this particular topic is using up more space than it would have in a code-editor 
So i end up with the notion of why waste time on yet another implementation (which would end up with similar results) ?
You know, you and me have been going back'n'forwards for more than a decade now, so you should know by now that i am a person of practical implementations, not hypothetical ones 
No matter how good the intention, practise always seems more reluctant to cooperate and, that seems especially true for AROS/Amiga.
Writing lines to a forum isn't like writing lines to a code-editor.
For me it's just relaxing. Taking a project and working on it requires a completely different attitude / focus, at least for me. But maybe it's just my personal problem.
I agree that implementing some feature is much better than discussing about it. However at least some discussions about requirements is beneficial to the project, because it might catch problems quite ahead.
With regards to personal beef between individuals, i am not going to bother with that other than stating that life is simply too short to get upset about these kind of things even though i understand that you wish to defend yourself in case someone put words in your mouth. It is all about perception/interpretation.
What was it again... live long and prosper ? 
Especially since we have just one.
I'll not reply anymore to the guy, unless there some technical (and only technical) discussion which deserves it. I've already wasted a lot of time which I could have spent acquiring some knowledge with capstone (I Python package which I need for my project), instead...
Well, in the end of this long and useful discussion.. any idea for a distribution?
I've already suggested what to do: provide one which is already pre-installed with all tools which Icaros provides.
You can add an hard drive to a VMWare virtual machine of a little bit 8GB (less than the space used by an 8GB USB Stick), partition it properly with GRUB, the SFS primary partition where Icaros is installed. Provide a 1GB SFS partition that might be used for storing some extra (non-system) data. And another 1-2GB FAT32 partition useful for exchanging data with the external world.
Once Icaros is fully working, just use the dd command to make a rough dump of the whole device (not partition), and provide it for downloading.
It should work-out, and should be easy to "flash" on the USB Stick using tools like Rufus.
Or... do you need something else?
