All of the post was very vague, meaning whatever details there were in the post are suspect.

You do like living 20 years in the past.

For someone to learn, it is criminal to not invest time looking at current technology.

There may be a lot of reasons to keep an ancient design alive for a couple more years instead of redesigning it.

There are basically no reasons to make new designs based on ancient technology. And there are basically no reasons to learn using ancient technology.

You are very much behaving like an unexperienced student, getting stuck on a single word in a post. Most posters don't know what they want, so they don't know what to write in their post. That means that many of the details you think you can pick up from their posts are actually noise that got added to the post by a series of random accidents.

But almost always, the only reasonable ways to behave is to either ask for more information to kind of "bracket" the request and get a better feeling for how much the requester actually knows and what information/ideas/thoughts they have missed to mention. Or alternative to give a short answer saying that "if you really want to use a 8031, you can ... but I would recommend that you instead consider ..."

Any real software developer should since a long time have learned to question the information given in requirements specifications. Is something requierd because someone knows that it is required? Or because someone thinks it is required? Or someone have heard about it before and tought it might be a nice feature? Or because a competitor maybe have such a feature?

When helping people on a forum, or when implementing real products, the original input information is a starting platform. But you don't just start running based on that information - you bring in your own know-how and start a two-way dialog to make sure that both you and the customer/requester have the required knowledge to set up the requirements. If the slightest in doubt, you make sure you get a description of what problem the customer/requester is trying to solve, to see if there are better/cheaper/faster/... ways to solve the problem. You then describe your found alternatives and give the customer/requester a chance to adjust their requirements based on the addition of your know-how. Implementing what is requested without supplying any own feedback is one of the basic problems with the development services available from India - companies sees very low hourly rates and think they have found an economical solution. What they get is a - possibly - working device that solves the wrong problem. Or that solves the correct problem in the wrong way.

So once more - a few sentences from an unknown poster on a web forum can not really be seen as "facts". More like hints. Writing answers believing that possibly very murky questions are correctly covering the subject is bound to very regularly fail badly.