GL_EXT_texture_filter_anisotropic
GL actually does define GL_NEAREST + anisotropy, but it modifies the behaviour of GL_NEAREST from being a "crunchy pixel" mode to being a "select the type of anisotropic filtering used" mode.
The extension notes that such hardware actually does exist. Maybe it did back then but I'm not certain that it does any more.
Cross-checking this extension with FitzQuake's checks for anisotropic filtering, I'm not sure what the intent behind the latter is, but the extension notes that 2 is minimum value so it would be sufficient for FitzQuake to just check for 2.
Setting to 1 disables anisotropic filtering. I'm not sure how well-known that is; disabling anisotropic filtering is a value of 1, not 0. Setting to 0 will actually throw a GL_INVALID_VALUE.
D3DTEXTUREFILTERTYPE enumeration
Direct3D 9 doesn't clearly define how anisotropic filtering works at all. You need a bunch of trial and error to figure it out yourself.
It does state that you cannot set an anisotripic mip filter, but you also cannot set an anisotropic mag filter - the D3D debug runtimes will throw "unsupported mag filter" errors. So anisotropic is for min filter only.
Setting max anisotropy to any > 1 value without also setting the min filter will not give you anisotropic filtering.
Setting mag filter to point/nearest and min filter to anisotropic will actually give you a blurry mag filter.
What a mess.
Decision time
I'm going to do the same as Spike and only enable anisotropy with mag filter = linear. It's clear from upthread that expected behaviour is "if I ask for crunchy pixels I want to get crunchy pixels".
I think setting them in the order that commands are issued is just going to create a mess that will eventually explode in your face. I do understand the visual feedback element, but that only applies if you're entering commands manually in the console. Whatever is chosen must also give expected behaviour with config files.