Is it? In fact I think it depends ==> the soft serial lib has an inverted flag, so that is a thing you should know too.
No, it doesn't depend on anything, no matter inverted or non-inverted, with asynchronous serial data the start bit and the stop bit(s) are always of opposite state of each other. A start bit is consider a SPACE bit condition no matter what the logic polarity is and a stop bit(s) are always considered a MARK bit condition.
Bottom line is that auto-baud detection can be as easy or difficult as one can imagine depending on the how robust and reliable one requires and if there is any assumptions or not one can make about the incoming serial stream. For instance what if there is no data arriving, does your detection function just block all further processing waiting for it to possibly be coming? Or should it be interrupt driven so as to auto-detect only kicks in when activity starts on the serial stream and does a one time check and never run again until reset or power cycled? Does on make the assumption that parity even or odd isn't being sent or that the stop bits are one or two (there is even a ancient 1 1/2 stop bit option). If parity is detected should the transmit response be made to match? It's one of those applications that the more you look into possible 'difficulties' the deeper the hole appears to be. I think most auto-baud rate detection methods just resign to be 'good enough' for the overall application and use whatever assumptions that the specific application allows one to take. It's a hard one to make bullet proof perfect under all possible conditions internal and external to the sketch.
My company purchased for us in around 1979 a state of the art hardware based asynchronous serial data analyzer, a model called the Data Hawk but I forget the company name. It had a small 9" crt screen and could be configured to display and or send at all the standard baud rates, show serial control signal statues, flag parity errors if configured, detect framing errors, display in ascii, hex, binary, octal data format, able to monitor in series with an existing serial circuit and display data from both directions, and many other features and functions that I can't even specifically recall. As I do recall it cost $12,000 and was invaluable in troubleshooting the many many mixed vendor systems we had in the refinery. One thing it didn't even try to do was auto-baud rate detect, one just had to keep trying a various standard rates until you could recognize a valid data stream. It's amazing that today just a standard arduino board and a little RS-232 voltage converter chips could probably duplicate the same functions, but the sketch would not be trival by any means.
Lefty