Sorry I missed the part you were talking about an “import script” . Also I think you are not fair here, 2.5 is still far from mature and the progress bar is the least of our concerns, dont compare 2.49 with 2.5 , there has been alot of rewrite with 2.5 and thats a very good thing, actually you should kneel before the blender developer that had the balls to do a rewrite on code, rewrites are as common in programming as comet naked eye sightings. You think that 3d studio max or Maya users will have the luxury of a rewrite on their awful gui in this decade, not even in their wildest dreams.
Progress bar falling through the cracks is a result of those rewrites, even slight changes in code are enough to brake compatibility imagine having a completely new api for python. I have always complained about the wiki being crap, but I also acknowledged that if a well organized wiki was so easy to do then it would have been done by now. Till this day I find it hard to believe that blender is free and open source. We are so lucky.
Now I dont know how blender triggers the progress bar, but if c can do it so can python, you will have however study the code and use ctypes. And of course the question remains do import functions even written in c are able to access the progress bar ?
Another way around it , you could make a progress report using your script gui, a label reporting a % should be enough. I tried it , it works , but it only refresh when the panel is redrawn and the panel is redrawn only when the mouse hovers over it at least with the tool shelf in view3d. Its not ideal that the user should hover the mouse to see the progress but it can work and its not that much of a problem. Afterall if the import is fast , I dont see much of a point for a progress bar. Also this approach allow you to show abit more information, for example if the script gets slow somewhere you will be able or your user to tell what kind of data slows it down or even crash it .