Your question about how the other editor handles this got me wondering, so I checked it out. On the bright side, what I found simplifies my explanation of what I wanted to see happen, but it also made it pretty clear that, at least the way it handles this situation, ME does not do it.
The other editor has two options: Tab Stop Value and Insert Spaces. The former controls the spacing of all tab characters whether they are entered via the <Tab> key or already exist in a file. The latter is used when the equivalent of ME’s Tab Expand/Expand to Spaces option is set. So you would not be able to interpret existing tab characters as X number of spaces and insert new tab characters as a different number of spaces. I didn’t mean to imply that this is what I wanted, but it seems that I did anyway. Since I always used the expand tabs to spaces option on the old editor and it did what I wanted I never paid much attention to how those options were actually being used by that other editor. I guess I should add that the Insert Spaces option is implemented like a tab stop (i.e. if Insert Spaces = 4 and the cursor is at column 2, pressing <Tab> results in two spaces, not four), so I can’t just set tab stops to 8 spaces in ME and map <Tab> to a macro that blindly inserts 4 spaces.
My comment about tab stops being generally accepted as 8 spaces comes from the historical hard coding of 8 space tabs by printers not the context of a language. If you’re interested, I dug up a Widipedia entry (http://en.wikipedia.org/wiki/Tab_key). My problem comes from our coding standards which require tab characters to be 8 spaces but indents have to be 4 spaces. Following these rules, I find a lot of files where 3 levels (=12 spaces) of indents is achieved by entering one Tab character and 4 spaces. This line in ME appears as if it is only indented 2 levels (=8 spaces) when the tab stop value is 4.
I hope this clarifies things. Maybe someone can offer up a solution since it appears my question has turned into feature request.