Map gets smeared out in a long hallway and the robot sees a wall that isn't there - SLAM tuning or something else?

I think you are right to lean hard on the laser data rather than the wheel ticks. In any narrow corridor, expecially if you are running on polished tile or wood, odometry is just going to accumulate error way too fast. I have seen my own platforms drift several meters over a single long hallway just by driving slowly back and forth. When it comes to trusting the map, I prefer the sensor to define the space. If the map is double walling, it's usually because the sensor is picking up reflections or the data is being processed too aggressively. That phantom obstacle blob you are seeing is almost always somethig physical near the sensor, not a software glitch.

In my expirience, it's usually a mount height issue. If your sensor is mounted too low, it might be seeing the edge of the robot's frame or the base itself as a solid, immovable object. I adjusted the height of my unit slightly, and the spurious readings vanished. Check the angle at wich the laser is hitting the immediate surroundings of the sensor; even a slight misalignment can create what looks like a solid barrier that isn't real.

I took on a project similar to yours last year in a decommissioned warehouse and I think relying solely on the laser readings might be missing the bigger picture. When my little rover went back and forth across the same spot hundreds of times, the map became incredibly noisy, which is exactly what you are seeing with the wall doubling. While odometry definitly accumulates error, it's not useless, especially if you are using some form of cumulative correction. My setup uses a Kalman filter to weigh the incoming sensor data against the dead reckoning of the encoders, which keeps the movement feeling smooth even when the laser data gets a little jumpy.

For the phantom obstacle you mentioned, I found that when the blob appears, it is almost always a side-scan issue rather than the robot seeing its own body. If the sensor is mounted too close to the chassis, the close range readings from the lidar might be catching the lower part of the robot when it turns a corner, presenting it as a solid object. I adjusted my sensor mounting height by about three centimeters, and that ghost disappeared immediatly. Also, consider that if the floor finish is extremely reflective, the laser pulses might be picking up specular reflections off the polished surface near the walls, creating false boundaries that confuse the localization algorithm. It is often better to treat the odometry as a guess and the laser scan as a check. If the check strongly disagrees with the guess, then you trust the check. But if the check is noisy, you use the guess to smooth out the inconsistencies. I think that balanced approach worked much better for my setup than forcing the system to rely exclusively on one piece of information.

That invisible blob thing happened to mine too. Turned out it was a coffee mug someone left on the floor that the spinning part coud see but I kept forgetting was there. Try watching the live sensor picture while the robot sits still and wave your hand around at diferent heights to see where the blob sits. Then check if that spot lines up with something on the robot itself. Does your robot have any little bumper or cable sticking out front that hangs lower than the rest of it?

You should also verify your sensor rotation speed against the corridor lighting, because with cheap units the reported ranges smear when the beam passes bright windows or overhead LEDs, and that smear looks exactly like a doubled wall in the map. I chased a similar ghost for two weekends before realizing the office glass door was reflecting returns that were actually four meters behind me. If your blob is ring-shaped in the raw scan viewer, check wether it appears at the same heading every rotation, which would point at a cable or mounting bracket clipping the beam path rather than anything on the floor.