In line responses email-style below:

> There is a major difference between Map and Lightcurve in that lightcurve is inherently time-based while Map is not therefore MapCube (a series of images in time) has no equivalent in lightcurve since it is ALREADY a series of measurements in time! 

Yes, and when we come to write a factory for spectra we are going to hit another set of problems, what we are advocating for is a uniform API, sure this means that some things might work more smoothly for some cases rather than others. However, I feel that the uniformity of the API is critical.

>Another example, say you ran the following
```python
goes = LightCurve(TimeRange('2012/01/01', '2012/01/02'), source = goes)
```
>This call just downloads two goes fits files (say goesfile1.fits and goesfile2.fits). Therefore, say, I already had those two files then the output of the first call should be equivalent to  
```python
goes = LightCurve(['goesfile1.fits', 'goesfile2.fits'])
```
>but you guys are advocating that the second call return a list of two lightcurves unless I call concatenate. 

In this case with `concatenate=False` the first example would also return a list of lightcurves.

> If users want two light curves objects (or a list of them) then they can very easily create such a list by looping over an array of files.

Oh hell to the no. We are not forcing our users to add in loops in Python code, which are very slow, there definitely needs to be a option in the factory to return non-concatenated files.

> My main concern is that MOST of the time users will want their data concatenated and it is annoying to force them to state this every time. 

There is a simple solution to this and every other comment you have made. We make `concatenate=True` be the default position. This maintains the same list based API behaviour as Map, and only introduces a, IMO, simple and very convenient difference to the factories.