"Do you really think that Epson engineers ways to piss off users so they can sell $3 worth of ink (this is the cost of a round-trip from MK to PK to MK)? "
This is a good question, and I believe that in order to understand Epson's lack of response to user complaints, it's helpful to understand the environment in which software is developed. I don't want to take a lot of time to talk about this in detail, but it's often helpful to understand that a corporation like Epson is not a unified entity, but that different groups and individuals within Epson are apt to approach firmware from different perspectives.
In the beginning, we usually see a focus group. At some point, the idea of auto swithing would have been proposed, and endorsed by enough people to get onto the feature list. The firmware developers would have created the auto-switch function, and the testing group would have gone through a test script to confirm the tests passed. The quality of the test scripts is highly dependent on the corporate culture.
Once the printer has gone into production, changing a feature takes a different route. The corporate culture has a great deal to do with how customer complaints are addressed. It's often thought that Japanese companies pretty much focus on the domestic market when determining whether or not there have been any customer complaints. Whether this is true or not, there is effort and cost associated with investigating a customer complaint. Unless there is a good tracking system in place, the company can easily receive thousands of complaints about a single issue, without it ever being perceived as being a problem.
Once a problem has been confirmed, or the behaviour of the software has been identified as being undesirable, the problem has a chance to be identified as a feature request. At this level, it generally doesn't take much to kill a change request - and yes, at this level, I can very easily envisage a manager type quashing a feature which will cost money to address, and which will reduce consumable consumption.
Even if a change request does get past all of the change approval processes, the "maintenance programmers" are generally much less competent than the primary developers, and may not have the ability to make even minor changes to the firmware. Again, this is highly dependent on the corporate culture, but few of the Japanese hardware companies have really strong software development expertise.
