How would they even know to ask upstream for support, rather than the fork? If you use package bar and have a problem, you would have to do a lot of digging to even find original progject foo and ask them for help (which wouldn't even make sense since it's a separate thing)
I guess that depends on how users go about finding projects on github to file issues. If, for example, the user has an issue with this NixOS package (or debian package/any other repackaged example), and they start by just searching "python ambee github" or "Home Assistant ambee github" (seems like a reasonable first attempt to me) they will likely find the upstream near the top of the results.
Now, some users will perform due diligence and maybe find the NixOS issue referenced in OP and look elsewhere, but many will find the project and immediately file an issue there in the upstream, leading to the author's main concern of "I don't have time to support NixOS issues".
Ah I think you might be right with this case where someone will just google that. I am not doing that but prefer to go to the package manager list find there there the project URL.
I was thinking that people will do the same or else how will they know if the github repository returned from search results is truly the one installed?
I am not using NixOS but in general every package manager links to the project homepage let’s say (or name of the project which for example in a GitHub fork is clearly different than the original) which in this case would be the fork.
So for example if this will be the case with a package I use I will report the bug to the fork because the package manager showed me their link.
I will not search for name-like projects or the original one and report there if a fork was distributed to me.
This is why I am confused why a fork is not solving the burden of possible bug reports. Also the fork assumes its own maintenance this is the purpose of the fork.