Is it some common scenario that user takes two + Xlets together or rather artificial case which may happen? Do we have
any user feedback proving this is a problem? 

Please update issue priority to some meaningful level, see http://wiki.netbeans.org/BugPriorityGuidelines
I suspect this is a P4 issue (or feature) ==> Minor usability problem. Rare case with hardly exist.

This isn't feature because "multi Xlet" option presents in the "Project Properties". And this is feature doesn't work.
By the fact - BD-J support divides into single Xlet and multi Xlet's supportes. Ability of used multi Xlet support
exists see http://www.netbeans.org/issues/show_bug.cgi?id=160437. 

According http://wiki.netbeans.org/BugPriorityGuidelines:
It can't be P3: "Part of a product feature is affected, a viable workaround exists" No any "viable workaround" for the
"multi Xlet's support"
I think that The priority is near the P2: "Product feature doesn't work, a workaround may exist but it's difficult to
use or impractical"
"Multi Xlet support" is more bigger and powered part of feature that doesn't work and there isn't any workaround.

No any "viable workaround" for the "multi Xlet's support" - I am not sure if you are kidding me or want to spent all my
time on this discussion, I still feel like I should increase all P3's to P1's if this is P2 ....
I think, you are still missing one major point - this situation could not happen without major user interaction. Project
is by default created with single X-let, the only single X-let is selected by default. This means, user has to provide
several steps to achieve this state - create second X-let, explicitly select the possibility to execute more than one
X-let and select more than one X-let. The reality, that you were able to achieve the state doe not necessarily mean,
that anyone else will be able so. All the other project types are allowing multiple X-let executions, so disabling this
is  not really the option at all.
These "temporary fixes" = "break everything else except me" is not a solution at all, I can add check/fail into build
process which will warn the user that multiple instances of X-let are not allowed - this is the only option, when user
switch from platform A which supports multiple execution to platform B which not. In such a case, the multiple execution
stays still selected.

$0.02

If you identify this issue as a P3, please go forward and mark all P3s as P1. :-)

This issue is just a consequence of several faults of omission, 
let me iterate over them:

1. There are no java application descriptors (JADs) in bluray discs.
   Please remove/gray respective controls in the UI.

2. There _are_ application descriptors in the Bluray Disc structure.
   Here is the schematic overview of Bluray disc structure:
   
   2.1. Root point is "index.bdmv" file - this is a binary file that enumerate 
      Titles in the context of Bluray disc.
      For every title, in the Bluray disc, index.bdmv contains a 
      respective entry with a reference to a BD-J Object (BDJO) file.
      The mapping between entries in "index.bdmv" and BDJO files is 1:1.

   2.2. BDJO file is a key point in the context of this discussion.
      They contain the Xlet-s related information, including:
        - pointer at JAR of the Xlet.
        - application_id and vendor_id of the Xlet.
        - Xlet class name.
        - Xlet arguments that will be provided through
          XC to Xlet.initXlet(XC)
        - Xlet lifecycle details.

   2.3. BD-J Platform must identify _every_ Xlet, that identification
      is described in details in MHP/BD specifications.

      In particular, any Bluray player (in general, any MHP terminal) 
      is not allowed to load/start two Xlets with equal pairs 
      application_id+vendor_id.

   2.4. Players must ignore PRF files' contents if
      application_id & vendor_id in BDJO aren't equal to respective 
      entries in PRF.
 
   2.5. In 2.2 it is clear that in BDJ, same Xlet class name 
   could be easily identified as different Xlet from
   viewpoint of Bluray Disc Player: if it is packaged in the 
   different JARs, and e.g., same or different BDJOs 
   contain respective entries with same class name
   but with different application_id and vendor_id.

Java TV/BD-J APIs facilitate the following:

 - Xlet could recognize what is the Title that is currently selected.
 - Xlet could start another Xlet, either by changing a Title, 
   or by terminate one (by changing a Title, too).
 - Xlets could communicate each other, where in the context,
   Xlet is the something that is identified by the Player as the 
   pair application_id+vendor_id.

All of this functionality and APIs are broken/cannot be used until 
accurate handling of  application_id and vendor_id is provided.

...
I would add that typical real life bluray disc's structure is:

 - Several Titles
 - For every Title, there are several Xlet-sin several jar-s.

===
Current level of implementation of BD-J in cdc pack is "HelloWorld" level:
and the level prevents it from being seriously considered as a 
BD-J content development tool.

Just imagine a J2SE development tools that does not let to
use a second class with the method "main". This would be a kind
of similar to this one, issue.

---
If you need more input, please go forward and 
ask me back.

Yes, it is Hello word level, no doubts .. there was not intent to do deeper support in our plans. If you see it as P1, I
would propose to remove BD-J support from distribution and put it on autoupdate/beta. We do not have any resource to
move it further.

BD-J functionality have been removed from standard distribution - it is not feature complete enough to be included
there. It will be available on Beta UC. Integrated in CS 9e1d7ec36628

Verified with NetBeans IDE Dev (Build 200907270201)