export from an anydbm-backed tracker produces .csv 
files with "is retired" set correctly.

import to a newly-installed sqlite-backed tracker 
completes, but on inspection through the web interface 
retired objects (users & issues are the two I have seen) 
have sprung back to life and are visible in lists & 
searches again.

import to a newly-installed anydbm-backed tracker 
completes correctly.

Bit of a bugger, because anydbm is starting to get a bit 
sluggish for us (and seems more so on Python 
2.3.2/dbhash than on the previous Python 
2.2.1/bsddb185) and sqlite is blazingly fast in 
comparison...

ActiveState Python 2.3.2 on Windows, with the current 
pysqlite (0.4.3 for Python 2.3) and sqlite dll (2.8.6).

Logged In: YES 
user_id=6405

That really is a bit of a bugger. Sorry, but I'm about to go to sleep. I'll 
have a look in the morning :( 
 
(and yeah, *dbm are pants compared to sqlite) 

Logged In: YES 
user_id=598066

No worries. I had a poke around the import code and I think I 
found the problem: 

backends.rdbms_common.Database.import_list, where "is 
retired" is true, updates the __retired__ flag to 1 first and 
then does an addnode which promptly sets __retired__ back 
to 0.

Switching the order of the addnode and the retire leads to an 
import which (at least at cursory examination) is as expected 
and correctly keeps retired nodes retired.

Logged In: YES 
user_id=6405

Thanks, I'm patching 0.6 with a fix based on your research. 
 
I've also implemented some new import/export unit tests. Fortunately, 
they didn't expose any new problems :)