Not strictly necessary, I think; e.g. pass relative-path to Ant and
then use

<pathconvert dirsep="/" property="class">
    <path location="/${file}"/>
    <mapper type="package" from="/*.java" to="*"/>
</pathconvert>

to produce the corresponding class name. Cumbersome however.

Too late for format changes in 4.0. In the future it would be
possible, though the syntax would be uglier. You would need to specify
<folder> and <arity> and (optional) <pattern> as now, but then
<format> and <property> would have to be enclosed in some other
element of which you could have >= 1.

I think it would be a great enhancement to have something like a 
dependent-attribute in the ide-action-tags.

In my opinion the <property> and <format> tags should be enclosed to 
a new tag in any case, because they belong together. Its not obvious 
from the xml-file (because there's no proper dtd or documentation for 
this whole file) that in a
<context>
    <property>FILES</property>
    <folder>${src.dir}</folder>
    <pattern>\.java$</pattern>
    <format>relative-path</format>
    <arity>
      <separated-files>,</separated-files>
    </arity>
</context>
section all properties belong to context, except property and format, 
which belong together to define a property.

This format would be more readable and help most of the < NB4.0-Users 
to use a freeform-project with their old own ant-files:
<context>
    <folder>${src.dir}</folder>
    <pattern>\.java$</pattern>
    <arity>
      <separated-files>,</separated-files>
    </arity>
    <property format="relative-path">FILES</property>
    <property format="java-name">CLASS</property>
</context>

The reason for this is to be able to have an ant-target to 
conditionally compile a file when executing it from NB.

As you said, currently its cumbersome however.

The <property format="...">...</property> looks OK. Still not quite
right, though: the separator (for >= 1 arity) is properly speaking an
aspect of the property you set, not the context.

Would also be pleasant to have a way to specify an alternate value format in
project.xml. E.g. when using XTest, if your context selection is a set of *.java
files, you may wish to define some property to be

    pkg1/Clazz1.class,pkg2/Clazz2.class

Currently you can only do this by some ugly tricks:

<action name="...">
    <target>t</target>
    <context>
        <property>includes</property>
        <folder>src</folder>
        <pattern>\.java$</pattern>
        <format>absolute-path</format>
        <arity>
            <separated-files>:</separated-files>
        </arity>
    </context>
</action>
....
<target name="t">
    <property name="base" location="src"/>
    <pathconvert property="reformatted.includes" pathsep=",">
        <path path="${includes}"/>
        <mapper type="glob" from="${base}${file.separator}*.java" to="*.class"/>
    </pathconvert>
    <!-- use ${reformatted.includes}... -->
</target>

It works - Ant can handle the input - but <pathconvert> is rather awkward for
this kind of purpose, and using <script> makes the build script less portable.
It would be more pleasant to be able to say e.g.

<action name="...">
    <target>t</target>
    <context>
        <property>includes</property>
        <folder>src</folder>
        <pattern>\.java$</pattern>
        <format>
            <replace>
                <from>(.+)\.java</from>
                <to>\1\.class</to>
            </replace>
        </format>
        <arity>
            <separated-files>,</separated-files>
        </arity>
    </context>
</action>
....
<target name="t">
    <!-- use ${includes}... -->
</target>

so that the file list is in the preferred format as soon as Ant gets it.

...which would also be handy if you wanted to map e.g. pkg/Clazz.java in the
selection to pkg/ClazzTest.java in the property. But the format I suggested
would not be enough to let you map it to pkg.ClazzTest; that would require two
regexp replacements. TBD what syntax would be readable yet powerful enough.

This will make implementing <target name="run-single" depend="compile-single"> 
much easier.

And the format will be backwards compatible if you choose the "multiple 
contexts" solution.

vnicolici: Using multiple <context>s in their current definition is not really
an option because <folder>, <pattern>, and the kind of <arity> (though not the
separator) would be required to be the same for all the contexts, which is not
expressible in the schema and would look weird to duplicate. So I think some
kind of format change is required. "Compatibility" is not really an issue since
we would just make a /2 schema to replace the old /1 schema, so there is little
advantage to making a syntax change that subsumes the older syntax, other than
keeping a familiar appearance. The trickier question is deciding when the new
version of the IDE should write a project.xml using the /2 schema - you don't
want to make the project unopenable in an older IDE for no reason. E.g. use /2
in newly created projects - yes or no? (Maybe.) When saving GUI config changes
to a project that used /1 and does not have to use /2 as a result of the changes
- yes or no? (Probably no.) When autogenerating context-sensitive action targets
and their bindings, which might require /2 - yes or no? (Probably yes.)

Changing the default component owner to tzezula.