Simple things like "requires OS/A" or "needs at least 64k RAM" are easy, but after you go beyond that things get _very_ tricky.
Requires/doesn't require BASIC is a very common one that is difficult to tell for newbies... mainly because some games require BASIC for completely nonsensical reasons, and because of Atari's annoying decision to require you to press Option to disable it instead of the other way around. A couple of Microprose games require it solely to display the splash screen during disk loading. Add to that modified OS ROMs that have the Hold Option behavior reversed, and it gets even more confusing. I remember struggling with this stuff even 20 years ago on the real hardware when I sometimes had to think whether a particular game required the Translator disk or not, whether it needed BASIC, etc.
Even the apparently simple cases get tricky when you throw in different emulators or emulator versions, though. SIO patch enabled/disabled is one such option -- Altirra can boot some disks in SIO patch enabled mode that Atari800WinPLus can't, because it has additional checks for unusual behavior. Conversely, there's at least one demo game that can only be booted in Atari800WinPLus with SIO patch enabled, because it calls into SIO after copying it to RAM and trashing part of it, and relies on A8WP's hook mechanism details to still work.
That having been said, it isn't necessary to cover all possible cases with a configuration mechanism. Just being able to cover the common options would go a long way toward usability.
You guys ever hear of something called file streams? That's what I use. I write metadata into a separate stream. Software that calls the filename directly calls the default stream by default (Disk Data). I read the metadata from the second stream as needed to provide runtime configuration information.
Do you mean streams as in alternate data streams (ADS) on NTFS? They're problematic for a few reasons: they can't be placed on removable drives that use FAT32 or exFAT, they don't go well in compressed archives, they're not very visible to the user, and my personal favorite reason, the .NET Framework actively blocks access to them by rejecting them during path validation.
I think changing any longstanding file format because some people can't figure out how to use an application is ridiculous. Either make the application simpler / more user friendly, or write a simple tutorial of how to set it up, use it, and what settings to try changing when something isn't working. If Avery was so inclined, I suppose he could make a simple mode for Altirra or something. But I certainly wouldn't expect him to do something like that -- He's already over-extended himself in helping the community in my opinion. With complex/capable programs comes a learning curve, as FJC said, whether or not you're an IT person, a programmer, or rocket scientist. Sure, an emulator for an Atari 8-Bit (and I include them all) can often be more difficult than the simple machines that they emulate. But that's because they do much more than any single machine does.
Can't deny that Altirra could always be made easier to use, but trying to make things simple/easy is one of the hardest tasks in programming -- it requires a lot of insight into how your UI is being used and the problems that users are running into, and creative solutions to the hairy problem that users don't read help text. It's not an area of program design to be underestimated effort-wise.
I'm afraid there is another reason that emulators aren't as play-and-go as they should, which is the need to avoid legal issues -- including making sure it isn't too ostensibly geared to playing mass-pirated game software, and not including copyrighted software that would otherwise be handy. The most glaring specific problem is the inability to bundle the XL/XE OS, thus requiring users to go out and get it, and then hook it up to the emulator. At this point, I've done the most I can by including versions of all four main ROMs that have been rewritten from scratch (OS-B, XL/XE OS, BASIC, 5200 OS). However, even this is foiled by the annoying tendency of people to still write new software that fails on anything other than the ver.2 XL/XE OS.