I'll work on this.

The culprit (or maybe not the real culprit, but the difference between
the stable branch and the dev branch which causes this problem to
appear) is a change in TaskListView.getFilter() where instead of
returning null when there is no filter in effect, it returns a
null-filter. By commenting that out (and making a couple of tweaks to
RemoveFilterAction) so that it doesn't throw exceptions, the expansion
handles are back and functional.

Tim, do you have any ideas in this area?  I'll continue looking for a
root cause.

Index: TaskListView.java
===================================================================
RCS file:
/cvs/tasklist/core/src/org/netbeans/modules/tasklist/core/TaskListView.java,v
retrieving revision 1.43
diff -u -r1.43 TaskListView.java
--- TaskListView.java   1 Jun 2003 06:33:58 -0000       1.43
+++ TaskListView.java   20 Jun 2003 20:45:23 -0000
@@ -1137,8 +1137,10 @@
      * no filter (e.g. all tasks are shown unconditionally).
      */
     public Filter getFilter() {
+        /* XXX hack
         if (filter == null)
             filter = new Filter(null, true, new ArrayList(), false);
+        */
         return filter;
     }
     
Index: filter/RemoveFilterAction.java
===================================================================
RCS file:
/cvs/tasklist/core/src/org/netbeans/modules/tasklist/core/filter/RemoveFilterAction.java,v
retrieving revision 1.2
diff -u -r1.2 RemoveFilterAction.java
--- filter/RemoveFilterAction.java      1 Jun 2003 06:33:59 -0000    
  1.2
+++ filter/RemoveFilterAction.java      20 Jun 2003 20:45:23 -0000
@@ -49,13 +49,17 @@
      */
     public RemoveFilterAction(TaskListView v) {
         this.v = v;
-        v.getFilter().addChangeListener(this);
+        if (v.getFilter() != null) {
+            v.getFilter().addChangeListener(this);
+        }
         stateChanged(null);
     }
     
     public void performAction() {
         Filter f = v.getFilter();
-        f.clear();
+        if (f != null) {
+            f.clear();
+        }
         v.setFilter(f, true);
     }
 
@@ -72,6 +76,10 @@
     }
     
     public void stateChanged(ChangeEvent e) {
-        setEnabled(v.getFilter().getConditions().size() > 0);
+        if (v.getFilter() != null) {
+            setEnabled(v.getFilter().getConditions().size() > 0);
+        } else {
+            setEnabled(false);
+        }
     }
 }

Fixed. From dev@tasklist post:

I realized why having filter==null was a problem; you have 
a change listener which activates/deactivates the RemoveFilterAction,
and this is registered with the filter. If there is no filter,
who notifies the remove action that it should be disabled?

So I did something else. I instead modified TaskListView to
use filter nodes if the filter has constraints (instead of
if filter != null). I also modified the show-suggestions action
to use an empty filter instead of null.

Things should work now - let me know if you see any problems.
Committed to trunk and merged to dev35 branch; module versions
1.9 (tasklist/core) and 1.8 (tasklist/suggestions).

It was resolved in 3.6 time or earlier.

Please, reporter, could you verify fixed issues. Thanks a lot.