1) Granted, long memory is a useful feature sometimes. But.
I think the memory depth is less important for the zoom level, than it is for the possibility to retain high sample rate at low timebase settings. Unfortunately there's no 1-to-1 correspondence betwen depth and sample rate decrease. (Have a look at my rant
here if you like.) I've haven't seen any scope datasheet stating at what timebase the sample rate goes down. You have to test that yourself to get an objective figure.
Having to choose between different memory depth is annoying. Automatic depth selection makes life easier.
Long memory may slow down scope response. Annoying. Check if it does.
"Segmented memory" is a very nice feature and in my opinion more useful than 10x more memory. If it doesn't have it, see to that it's an option.
I think at least 1Mpts/ch, but more than 10Mpts/ch no great advantage. There are pretty cheap protocol analyzers that can do better job for SW debug.
2) not necessary if you have 1GSa/s and only 200 MHz BW
3) Useful somtimes but may play tricks on you, especially when you're not so experienced with scope. But anyways, most scope have it, don't they?
4) Select a scope that already have, or at least you can upgrade to serial trigger/decode. Some scopes come with serial trigger but decode is optional upgrade. You'll likely to end up with a I2C or SPI interface to a DAC, ADC, etc on some design some day.
5) Naturally is quality important, not so much more to say. Meaning "avoid the chepeast crap".
6) At least 4 channels. You can get away with two channels but it's tedious. Startup behaviour and SPI are two examples. You may even find yourself in a situation where two channels just ain't enough. Option for digital channels will be useful for any design involving CPLD/FPGA(external memories etc.
7) General usability and user interface. Separate knobs for each vertical channel is mandatory (for me). Fast response to knobs and buttons. Frequent used features shall not need you to move your hand over the scope like you're waving away a mosquito. Fast saving of data to USB stick or computer.
8 ) Display resolution: the higher the better. However, how data is processed/displayed is probably more important (with reasonable minimum resolution). Anti-aliasing function avoids confusion.
9) Capture/acquisition rate...the higher the better of course. But the datasheet capture rate doesn't say much; test yourself and see what happens with more channels, different timebase settings, etc.
10) Rise time is more important that bandwidth, but of course they are related. Logic rise/fall times are down around 1 ns nowadays, so go for 200 MHz (or 100 MHz to start with if you can upgrade to 200 MHz).
//C