Can not use an id of a deleted image

This is correct behavior. The reason you can't reuse a deleted image ID is that it would allow the following bad behavior:
1. create a good image people would want to use
2. share the image, either using image sharing or by giving it community visibility
3. get people interested in using the image
4. delete the image
5. using that same ID, upload a new image that has some kind of bad stuff in it (a backdoor, tracking software, etc.)

This is described by https://wiki.openstack.org/wiki/OSSN/OSSN-0075

Also, here's some information about OSSN-0075 and the glance database management tool: https://docs.openstack.org/glance/latest/admin/db.html#purging-the-images-table

Right,

But if I want to use an automatic script, how to know which are these ids? This is my intention. I check if the image exists using the id provided by the user and if the show images operation does not reveal that any image exists for the id then this means I can create the image for the user. If I understand, the only way so is to try creating the image and in case of a conflict error, I retry the image creation. However, the coding of this sounds to me not so pretty. There should exist a way of knowing which ids are allowed to be used to avoid depending on exceptions in the logical flow.

Have you a suggestion?

I'd suggest you reconsider your workflow. Why does a user need to specify a UUID in the first place? Just let the system assign the UUID, and encourage your users to supply image properties so that they can identify the image. This will give you an overall better user experience -- is it easier to recognize 2d4ec3e1-d8cb-4aa2-ab6c-5c8248de3d96 as the image I uploaded yesterday, or an image named "CentOS 7 LAMP stack 2019-10-10"?

Being able to specify a UUID on image creation was introduced for a special case, namely, that of public clouds divided into isolate "regions" where it would simplify some things to allow a particular public "base" image to have the same UUID in every region. But it's a better practice to annotate an image record with custom metadata that will allow you to write a script to search for the particular image you want.

As far as prettiness goes, you need to be prepared to handle a 4xx response when you try image creation. For example, a container_format or disk_format you want to use may not be supported in that cloud.

One other thing: only an image-list response for an administrator will contain all the image IDs currently in use. If you're a regular user, you only see the image IDs of images that you own. So if Fred owns 2d4ec3e1-d8cb-4aa2-bb6c-5c8248de3d96, and Barney makes the call GET /v2/images/2d4ec3e1-d8cb-4aa2-bb6c-5c8248de3d96, Barney will get a 404 (Not Found). Barney doesn't get a 403 (Forbidden) because we don't want any information leakage that resource 2d4ec3e1-d8cb-4aa2-bb6c-5c8248de3d96 exists--it's not Barney's business because it's not his resource.

I'm mentioning this 404 instead of 403 design decision, which has always been part of Glance, because it implies that returning a list of all in-use IDs to anyone but an administrator is not something that we'd implement. Similarly for an API call that listed all unavailable IDs.

Thanks for the detailed answers. Help me a lot. Thanks in advance.