The description of fields is confused

Generally the leading slash works fine.

Perhaps the leading slash causes a problem if Drupal is accessible in a subfolder or similar?

IIRC in drupalci Drupal is tested in subfolder, but the tests are likely not checking that the URLs would actually work in a browser e.g.:

https://git.drupalcode.org/project/jquery_update/-/blob/7.x-4.1/tests/jq...

$this->assertRaw('<script type="text/javascript" src="/sites/default/files/jquery_update/jquery-ui.min.js?v=1.13.0"></script>', 'Custom jQueryUI 1.13.0 from local path');

We'd want to update tests if the examples change.

Yes, you're right. I faced with the issue in Drupal multisite. Shall I add this information in description and possibly update tests?

Sorry for the very slow reply, but yes - please feel free to update tests if you can to show definitively whether a leading slash is required, or conversely does more harm than good.

Alternatively, we could treat this a documentation issue?

..and/or tweak the admin UI so that it adjusts the examples / does validation if it detects that Drupal's running in a subdirectory.

I'm open to suggestions about how to improve this for the subdirectory case, but we need to ensure nothing's broken for the (majority) case of Drupal not being in a subdirectory URL-wise.

I'm not sure if this was a perfect solution, but I've tweaked the admin form so that it tries to generate the example relative paths with the actual path to the public files dir.

I've also added a comment to suggest that the examples are just that and may not be correct esp. when Drupal's in a multisite or a subdir.

Automatically closed - issue fixed for 2 weeks with no activity.

Maybe I'm misunderstanding the dismissal of the problem? I don't have a subdirectory in the URL to the site, it is just https://mydomain.local/, and when drupal_build_js_cache() tries to load the jQuery files, it is doing a file_get_contents() call on literally what is in the jQuery Update config - eg "/sites/all/libraries/jquery/jquery-3.7.1.min.js". That fails as you would expect.