As @Aurora suggested, this is a bug in SQL Local >= 2017 and Microsoft doesn't seem to care so much about it. The reason is probably because LocalDb is not supposed to be used in production environments. @Aurora suggested a workaround which is good, but it needs to be done manually.

To overcome this issue in your software, you can implement the following workaround:

1. Create a helper process / background task that runs every 30 seconds or so.
2. Check if the instance is started (using a SqlLocalDbApi class or by running sqllocaldb i {your_shared_instance_name} in a separate process and get the result). Also, record the named pipe at this point (format: np:\\.\pipe\LOCALDB#AC471EDC\tsql\query - to extract the pipe id value use this regex: #(.*?)\\ -> if matched use match.Groups[1].Value)
3. Verify the instance pipename by checking the following registry: SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\\{your_shared_instance_name}
4. If the recorded pipe name from point 2 is different from the registry value, update the registry key InstanceName

(C# example)

Get the key:

using var myKey = Registry.LocalMachine.OpenSubKey($"SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\\{instanceName}", true);

If it's different from the pipe id:

myKey.SetValue("InstanceName", $"LOCALDB#{pipeId}", RegistryValueKind.String);

Conclusion

Now everything should work. Checking it every 30s or so ensures that in case of Db Process failure/system restarts/etc if will recover just fine. Sorry, but this seems to be the only solution to keep LocalDb alive after 2017 upgrade. The other solution would be to migrate to SQL Express server.

This is only a sample of the code, but hopefully, you get the idea. If not, please leave a comment and I will try to help you. I struggled with this for a bit but it finally runs as LocalDb 2014/2016 without any issue whatsoever.

As Aurora suggested, this is a bug in LocalDB >= 2017 and Microsoft doesn't seem to care so much about it. The reason is probably because LocalDb is not supposed to be used in production environments. The suggested workaround is good, but it needs to be done manually.

To overcome this issue in your software, you can implement the following workaround:

1. Create a helper process / background task that runs every 30 seconds or so.
2. Check if the instance is started (using a SqlLocalDbApi class or by running sqllocaldb i {your_shared_instance_name} in a separate process and get the result). Also, record the named pipe at this point (format: np:\\.\pipe\LOCALDB#AC471EDC\tsql\query - to extract the pipe id value use this regex: #(.*?)\\ -> if matched use match.Groups[1].Value)
3. Verify the instance pipe name by checking the following registry: SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\\{your_shared_instance_name}
4. If the recorded pipe name from point 2 is different from the registry value, update the registry key InstanceName

(C# example)

Get the key:

using var myKey = Registry.LocalMachine.OpenSubKey($"SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\\{instanceName}", true);

If it's different from the pipe id:

myKey.SetValue("InstanceName", $"LOCALDB#{pipeId}", RegistryValueKind.String);

Conclusion

Now everything should work. Checking it every 30s or so ensures that in case of Db Process failure/system restarts/etc if will recover just fine. Sorry, but this seems to be the only solution to keep LocalDb alive after 2017 upgrade. The other solution would be to migrate to SQL Express server.

This is only a sample of the code, but hopefully, you get the idea. If not, please leave a comment and I will try to help you. I struggled with this for a bit but it finally runs as LocalDb 2014/2016 without any issue whatsoever.