I don't think it's useful to consider "entropy questions" categorically at this time, since we only have the one question, which may not even be in scope. We certainly don't need to create an entropy tag.
Regarding the migrated question, I tend to agree with your listed points. The author's comments indicate that they agree it belongs on Physics and emphasize a lack of interest, or maybe a lack of concern, about implementation problems:
I don't think this is about waste heat recovery. I'm not concerned with the quantity of heat recovered, but how to minimize entropy generated by storing and using it. I think that practical limits may make it difficult to implement such a solution, so I do, in fact, care about minimizing entropy, not maximizing heat recovery, which is actually quite trivial.
I do think the question is of some interest to some engineers and the line between pure theory/physics and applications/engineering can be very blurry but given the comment above, and the other comments left here since the migration, I expect it would be very frustrating to handle here.
I've rejected the migration by voting to close as "too broad" based on the author's stated lack of interest in practical concerns for the design and implementation of the cogenerative array itself.
As much as I personally feel this question could be appropriate for Physics SE, we obviously can't dictate scope to another site; what this approach does is keep the current formulation of the question on Physics, where the author has the option to pursue:
- modifying it to bring it into their scope;
- debating its merits on Meta Physics SE;
- deleting it and asking a new version of the question here on Engineering SE.
In the latter case, we would expect a reformulated problem statement to allow for the possibility that an expert engineer might conclude that the entropy concern is de minimis, allowing for solutions that ignore entropy generation entirely. In other words, a practical problem would have to be clearly identified, which "minimizing entropy generation" appears not to be.