It is currently possible that someone accidentally defines two or more occurrences of a do_foo operation. A real world scenario brings me to this report because I experienced that someone accidentally added two do_install() function definitions into the same recipe file. This caused a bit of work for the person to pin the issue down. It is more time if you are not experienced enough with the Yocto project. It could boil down from a few minutes to a few hours or days. It would be nice if bitbake could provide a warning in such cases. Note that it is possible and intended that such functions can be overridden in .bbappend file, but here I am referring to the override happening within the same file. It could even go to WARN_QA so that it would be possible later to turn such warnings into errors if the end users wish to do so.
Its not possible to tell the difference between someone intentionally overwriting a function and someone doing it accidentally. We do intentionally override functions on a regular basis in common metadata. The syntax we have simply doesn't give us a way to solve this so we can't do what you propose.
I do not follow. Could you please provide a bit more explanation, at the very least examples? In worst case, a blacklist filtering could be added for which packages, it should not check, but I really do not see it fun people wasting time with such things which can be automatically caught by the system in most cases.
Bitbake stores everything as key/value pairs regardless of whether its a function or a variable. Even just limiting our scope to functions, base.bbclass defines do_configure, autotools redefines it. There are hundreds of different cases where things are defined in one place and then redefined some place else. This is perfectly normal behaviour for the way the metadata is defined to work. So no, we're not adding blacklist and whitelist filtering.
"There are hundreds of different cases where things are defined in one place and then redefined some place else." I wonder if the bugreport was clear, based on that statement. The bugreport is writing about defined and redefined in one place, not one place and somewhere else. I am not saying that the latter is invalid, but I am saying the former is.