So what exactly is the bug here?

The fact that Jenkins doesn't allow you to reuse build numbers?  Can you show me where such a use case would be valid or helpful?  How is deleting builds like creating a new job?

Imagine for a second that you have a job with 10 builds (#1 through #10).  Let's say that you were allowed to change nextBuildNumber from 11 to 5.  What will happen when you run the job?  Will you have two builds #5?  Perhaps Jenkins is supposed to invent a #5.1 (5.2, 5.3 and so on) concept just for this?  Or do you expect the old build to be blindly overwritten by the new one?  Under what circumstances is build history overwriting helpful?  Are you comfortable with having a build #5 that is newer than build #10?

I'm mostly asking all these questions out of curiosity.  The Next Build Number plugin (that's how you tagged this ticket), has nothing to do with what you're asking - that functionality is part of Jenkins core.  The plugin merely asks Jenkins to change the next build number, and Jenkins core decides what values are acceptable.

Regarding your latest edits to the description:

I think you are referring to having earlier builds discarded (by setting, for example, the build to keep only the last X builds).  So now you have, say, 10 builds with the most recent being #1000, so 991-1000.   Then you, for reasons that you still failed to explain, would like the next build to be #500.  Let's imagine that you get your wish.  What happens when the builds reach 991 again?

Also, you may be failing to recognize the fact that among those organizations you referred to, many are using the build number to be the system of record for a version component of their software releases (or similar processes).  In such use cases they must never repeat.   For instance, in multiple organizations I've worked for, in a product release version "1.2.3.4.5", the 5 comes from $BUILD_NUMBER. 

I've asked a number of questions in my previous comment, if you'd like to continue this thread then please address them.  If you don't, feel free to close this ticket.

So, I have a series to identify a particular build belongs to some release of the product. the same job can be executed for any release in that case if I started a build with 8000 and then I decide to change to different release which starts from  99. To change the build from 8000-99 I have to delete all those builds or delete the job and re-create a new one with 99 as next build number. In any case, I have to loose my build data right. If you can provide a mechanism to delete or skip the existing builds if reach to 8000 again at least I will have an option to check back old 8000 build, for at least a minute. If I set like only last 10 builds are enough for a branch or job then 8000 will be gone by the time 99 build reaches to 8000 (if this is available I don't even have to worry about going for lower number needs other builds to be deleted and can have 2 different releases stay for couple of days and then old release gets deleted at some point new one will continue. Well, in any case, i can manipulate build number if you feel working on this is not worthy enough please mark it completed.

the following is screenshot shows 2 builds with same build number and 2 different graphs as well with the same build number.

I think that you are misunderstanding the purpose of the build number, and are using it entirely incorrectly because you want one job's build number to mean different things on different days.  Neither I nor the Jenkins core team are likely to ever give you what you are asking for.  

I see two options for you:

1. If you want to continue to use $BUILD_NUMBER as your system-of-record, create distinct and separate jobs for each release type so that each job represents the next release version for that specific release type.  If there are a lot of release types (and thus many jobs), I'd recommend you look into bulk job generation with the Job DSL plugin.
2. Stop using the $BUILD_NUMBER as your system-of-record.  Continue to use one job, but do not rely on $BUILD_NUMBER (thus you won't care whether the build numbers go up or down).  Use a separate system to keep track of your incremented versions per-release-type.  Use a database, a text file, whatever.