Today is Debian 8 release day

I've long forgotten exactly why these systems were first set up that way. Presumably it was because at the time someone was leaving their options open about the RAID set-up for the main drives/partitions and bootloaders of that generation didn't support MD well so keeping boot as a non-RAID set-up was not uncommon. Whatever the history, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.

How do you expect the upgrade process to even be able to take that kind of thing into account?

I don't think it's rocket science to suggest that if you're migrating to a new bootloader, and you've got a system with multiple drives in it (RAIDed or otherwise), and you're installing an OS that is widely used in server or multiple-OS environments, just assuming that you should upgrade the bootloader on one specific drive and ignore anything else is not a great idea. What if the sysadmin installing the update wasn't the person who installed the original and simply hadn't realised how the /boot was set up?

Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.

There was no "error". The situation before the upgrade was what it was, and after the upgrade the problem was quickly detected and fixed. But it took time and effort to do that, instead of having a smooth, fully automated upgrade process. Again, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.

Will the 7-to-8 update now expect everyone performing it to be intimately familiar with the implications of things like systemd? Because I'm betting plenty of people will encounter it for the first time as part of this upgrade cycle.

What about package compatibility? Some packages have been entirely removed in Jessie; see the political debates about FFmpeg vs. Libav for a relatively high-profile example. That is inevitably going to break some people's install scripts/tool recipes/etc.

My point here is that there are significant changes as part of the upgrade, and upgrades always carry a degree of risk, and my personal experience (based on several different projects) of the 6-to-7 upgrade process was that the risk was real and the fully automated part of the process was not able to do everything necessary itself. Consequently I would not recommend that anyone assume a 7-to-8 upgrade will necessary go completely smoothly and be fully automated either.

[Edit: To be clear, I'm not saying you shouldn't do it or something awful will happen. Nor am I criticising Debian for not anticipating every possible scenario and handling everything completely automatically. I'm just saying my experience last time around was different to kasabali's experience, and as one data point, projects I work on where the experience was not as smooth last time but the desire is to move to 8 quite quickly are generally favouring a clean install and application migration strategy rather than an in-place upgrade. The expectation of those teams is that this will incur less risk and might be faster anyway once you take all implementation and testing effort into account.]

As such, upgrades may be painful if you have anything esoteric in your configurations.