I've also been testing collective.recipe.vscode occasionally for the last month and it really has some potential.
Issues I've had is that the recipe tries to modify an existing .vscode/settings.json, If the existing json has any 'strict' json errors the recipe will crash on pythons json module trying to deserialize, Took me a while to find sparse ',' at the end of an attribute list.
Also the recipe overrides/bumps into other fields for black and linting you might or might not specify and are already present in your settings.json . I'm not sure if I should like that it overwrites the settings.json.
I'm not sure yet if I want the recipe messing around with all those settings as well: one other useful option it has is to generate an .env file in the .vscode subdirectory which contains the correct PYTHON_PATH for all your buildout eggs. If it could only that and not touch the settings.json that would be nice.
Another thing the recipe does is setting the path to the python interpreter correctly, but I already found a differen solution for that by using the workspaceFolder variable substitution.
A returning discussion we have at our office on editors and IDE's if you should always install all your add'on utils like black, pylint etc. in every buildout/site project or if you should agree between developers working on a project where your local tools are installed (we also have a tools buildout).
You could also configure 'account' wide settings in the user.json, but I've had little success with the python Interpreter settings, especially when I'm opening both python2 or python3 projects .
Any tips from others?