To address the filename collisions, FIFO and directory limits, all customers will upload to a separate subfolder.  THe adapter will then pick them up using the "Subdirectory Levels" parameter set to 1 or 2.

As for the question of why, since you took some time to reply I'll gladly share my reasoning now :)

1. Management

  If I have 18 customers and have to create 18 adapters, what happens if the DNS name for my FTP server changes?  I have to update all 18 adapters. 

2. Deployment

  Creating and configuring an adapter takes time.  If everything is managed through two lookup tables, I can easily automate the deployment with a CSP page by filling in two fields and clicking a button.

3. Resources

  Granted, I don't know how Ensemble works at this level, but my assumption is that 18 adapters monitoring 1 folder would use more resources than 1 adapter monitoring multiple (sub)folders.  

4. Clutter

   Productions are scary enough.  This may seem petty, but it truly bothers me and leads into the next point...

5. Human error

  The opposite of SPOF is MPOE (Multiple Points of Error)!  What if I double click the wrong service to disable it?  What if I have the wrong one selected?  This might apply to the lookup table interface as well, but what about individual adapter settings?  I've duplicated them 18 times, the chance of making a typo is significant.

SPOF:
   Generally when you talk about a single point of failure you are talking about redundant systems.  A network or a power supply.  Systems where if one thing fails, the system itself still works.  In this scenario we are talking about multiple workflows, or systems, which all have single points of failure.  So I feel like it's apples to oranges.  Besides that, how often does a single Ensemble adapter/service fail?  That seems highly unlikely.  More likely that the production would fail which would make this irrelevent anyway.

de-coupling:
  This is not inherantly a good or bad thing.  Maybe in programming where coupling is easily defined, but in this context I need more details as to why this would be good.

Monitoring:
  If you're talking about actual up/down monitoring, refer back to my points on SPOF.  Also, I could just as easily monitor the individual FTP servers if I wanted to.  On top of that, montioring is as abstract as I want it.  I could monitor (and do) all inbound messages from each customer, regardless of what adapter/ip/port/system they come in on, into an aggregate picture that tells me when something is wrong with any feed from anybody.

This is a good point, but I think we all agree that StackOverflow is the crème de la crème of Question and Answer communities and they allow editing even though their entire site is based on up and downvotes.

-1

(just kidding)

Okay I submitted a proposal.  It's waiting for peer review.

Give me an idea of what you would like to change and I can either make the change or propose some wording for you.

edit: Or I could use this paragraph from Wikipedia:  

Caché ObjectScript (COS) is a part of the Caché database system sold by InterSystems. The language is a functional superset of the ANSI-standard MUMPS programming language. Since Caché is at its core a MUMPS implementation, it can run ANSI MUMPS routines with no change. To appeal as a commercial product, Caché implements support for object-oriented programming, a macro preprocessing language, embedded SQL for ANSI-standard SQL access to M's built-in database, procedure and control blocks using C-like brace syntax, procedure-scoped variables, and relaxed whitespace syntax limitations.

What do you think?

The ObjectScript tag wiki doesn't mention anything about Cache or Intersystems.  I actually thought it was an intersystems technology, are you saying it's not?

If you don't have enough rep to propose a change to the tag I would gladly do so if you want to propose any changes.  You definitely have enough rep to propose wiki edits.

Any thoughts on utilizing/promoting Stack Overflow instead of duplicating efforts and fragmenting support?

I think I see, you'd have to do this first though, right?

#Define YES "1"
#Define NO "0"

Nah, don't remove it.  I have a great headstart!  :)