If you mean that it is irrelevant in determining whether the bug must be split, then I agree and, as I mentioned in my previous response, I would personally prefer the bugs to be split to provide more flexibility. In general, I find that many of the bugs we have sometimes evolved to include more (sometimes tenuously related) issues than the one for which they were initially created, and it is my opinion that we need to be careful about this in the future.
However, there are deeper needs that need to be addressed now and then, and with all due respect, I disagree that we can look into this later.
Please correct me if my thinking is incorrect, but it is my understanding that since this bug is not closed, there are issues that currently exist in the installers that, even if unannounced, have been provided on the download site. This means that it is possible for people to have access to them and, therefore, potentially run into issues with the tool.
As such, we need to understand the potential issues and these differences and their impact (consequences) based on the various installation methods selected. We need this both to properly guide our users in making the correct choice of the installation process and, more importantly, to manage their expectations once the tool is installed.
Without knowing the consequences of the differences in installation, we cannot properly manage user expectations, which often leads to dissatifaction - even in an incubation setting. We need to, nay must, be proactive in these matters.
This would only become moot if there are no differences in the installations and there are no issues to tell the users. Is that the case?
Knowing the consequences will also help in determining the severe and urgency of required fixes, e.g., do they need to be fixed in a 0.8.1 release? Can they wait until 0.9?