CIAO features users liked the least

9 - long parameter inputs

14 - hidden parameters

18 - Slow, SEGVs happen occasionally, require lots of memory

19 - The inability to run multiple instances of the same tool at the
     same time, even on different machines, without complicated setup
     (using local parameter files, etc).  It is extremely time consuming
     to, for example, extract spectra for 2000 sources one at a time on a
     single machine while other available machines sit idle.

24 - I don't know.  I don't really use the ones I don't like.

28 - syntax is nonintuitive and awkward

29 - some of the low-level tools (dmlist,dmcopy) are much less intuitive
     than their ftools counterparts.  Also, something like xselect would be
     nice.

33 - Many tools require an unreasonable amount of memory and cpu time.

35 - Grating threads are not very straightforward.

38 - sherpa - absolutely useless....

39 - Very frequent updating of CIAO.
     When is it going to be stable ?

43 - sherpa's inscrutable, context-sensitive commands
     chips extreme verbosity for simple tasks.
     slow (any equivalent, e.g., fselect vs dmcopy, is faster).
     hybrid syntax (slang and command line)
     large code size; large parameter sets; frequency of segv's

47 - Execution speed. Various tool instabilities. Obscure error messages.

60 - Sometimes it is not convenient to download the thread, the website is
     very slow.

62 - chips - there are already plenty of plotting packages in the
     world - why adding another one.

63 - Some of the tools are just too slow.  I think you know which ones
     I'm talking about ;-).

64 - I don't use the spectral analysis tools.  I prefer XSPEC.  Also,
     it would be helpful if the photometry and/or positions from wavdetect
     were more reliable.

69 - csmooth - its slow and is too much of a 'black box' program. I've
     started using my own adaptive smoothing programs.

71 - parameter files

72 - syntax/parameter name changes when changing version of ciao
     (i.e. change from param "ccd" to "chip" in merge_all, or
     [dm|ps]extract now using aoffs, now asols, now expmaps..)

75 - speed (especially sherpa, csmooth), stability

82 - that command line inputs change between versions, often breaking dozens of scripts

     that little time/effort is being devoted to PSF library enhancement.

83 - I want it to become more faster

90 - It is annoying that if one forgets an "=" sign when using pset, that 
     other parameters get screwed up.

99 - Sherpa manual a disaster to read -finding things difficult,
     written poorly, at times incomprehensible.

100 - examples in ahelp are often trivial
      need links to other ahelp tasks that explain how to get the
      files needed by this one

105 - Sherpa. I found it difficult to use and I gave up.

108 - complicated to do any reprocessing because of many arguments for 
      each tool etc.  Many can be scripted - like psextract

111 - new features, where it is not clear if it is very important to
      use them and to redo the full analysis

115 - the way I can waste huge amounts of time puzzling over syntax or
      obscure documentation, without gaining any understanding of how
      anything works

121 - sherpa

124 - Speed.  Speed.   Speed.  
      Sherpa and many of the tools are excruciatingly slow.  One
      reason I fall back to Funtools and Ftools is to get better throughput.
      For example, converting a script over to using funcalc instead of
      dmtcalc provided a big performance improvement.  I was using funimage
      instead of dmcopy for awhile, and I'm thinking of going back to
      funimage.  (The main downside is having to fix up the various
      header keywords.)

      I always use funtools if they will do the task (e.g., I always
      use funhead to examine the FITS headers.)

      The ~/cxcds_param is a royal pain.  I often have multiple 
      analyses going on.  The only way to keep from clobbering myself 
      is to work hard to ensure that everyone has their own local uparm.
      A large motivation for wrapping everything in scripts is to allow
      me to have the script set up the (huge) ciao environment, and 
      set up a local uparm.

      Periodically I find myself deleting the contents of 
      ~/cxcds_param and then write-protecting it.