As I participate more and more in different distribution lists at Microsoft, I'm starting to here more and more poeple complain about BCC emails. Honestly, I've always wondered what the purpose of BCC was if not to send an email to yourself when you send one to someone else. Honestly, that's probably the only use I've gotten out of it for the past 8 years or so. Then, I noticed people replying to email that pertains to one distribution list and not another by BCC'ing the one it doesn't apply to, noting that it was BCC'ed. The purpose here, as I've come to understand, is that unrelated email is moved to a different, more appropriate thread and anyone who's interested will know where to go find it. The problem with this is that, when you BCC someone, you break email rules that people have setup. While I completely understand this, BCC is not the norm, so I just accept it. Besides, email rules are never 100%, anyway -- at least not for me. I can see both sides of the coin, so it's definitely not cut-and-dry. To get around this, people suggest you send 2 emails: one explaining that you're moving the conversation to another location and another to that other location with all pertinent parties CC'ed. I like that this abides by rules, but this is just too much effort. Plus, I like seeing what the comment is that is sending someone away from my distribution list when it is transferred elsewhere. This, of course, is what led me to my suggestion: add the capability to fork or branch an email into two (or more) emails. In its simplest form, you would identify one or more people that you want to be broken off of the re-all list and send your email to everyone as you currently do. Then, Outlook (or perhaps the mail server) would send out multiple messages to the only the parties you specified. This would allow you to send one email to everyone who was being removed from the list and another to those who are staying on it. The only problem I see is that the logic and selection process to choose who is and isn't to remain on the list could be a pain. Nothing horribly difficult, but you'd definitely want to make sure it has a nice user experience.
One thing I am continually annoyed with when working with the Visual Studio test framework is that, when a test fails, I have to look at the error to figure out what line of code in my test method caused the problem, then separately find that class, browse to the line, and figure out what's going on. This isn't how we do our development, so why is it how we do our unit test development? I know this was a v1 release -- although I hate that excuse -- but I hope we'll see some significant improvements in Orcas.
Edit: Looks like this was reported on VS 2005 beta 2 and ultimately closed with a claim that it was added to the RTM release. Obviously, it wasn't, so I added another suggestion . We'll see what they say.
Edit: According to the folks at Microsoft Connect, this will be in VS08. I look forward to it!