I don't think it is a bug (let alone a severe bug) that a GUI behaves differently for the first and for later startups. It is up to the GUI to decide what the most efficient course of action is to honor the guarantees of the protocol specs. And the only guarantee is that when you send done=0 the GUI won't overlook any of the engine's features upto the next done=1, no matter how tardy the engine is in sending them. If this is because it really waits for the done=1, or because it already knew all the features from a previous engine run is no business of the engine.
It has been mentioned in the XBoard mailing lists that this behavior could be considered a minor bug, because in theory the user could replace the engine binary by another one, which would send different features, during the session. My take on that is that the reuse=0 feature is not intended to facilitate such wreckless behavior (and it would be impossible in Windows anyway to alter a currently running binary).
alternative specs wrote:Your engine should send one or more feature commands immediately after receiving the "protover" command, since xboard needs to know the values of some features before sending further commands to the engine. To prevent unnecessary waiting by the GUI to see if more features will be coming, it is strongly recommended to send feature "done=1" as the last feature command. This will inform the GUI that all features have been sent, so that it can proceed immediately.
Otherwise the GUI might wait for upto 2 seconds before it concludes that it has received all features. If your engine for any reason needs more time than that, send the feature "done=0" before the other feature commands. This guarantees the GUI won't miss any features upto the following "done=1". If needed, it is okay for your engine to send done=0 soon as it starts, even before it receives the xboard and protover commands.