Ashley, would it make sense to offer an import of sprites, and spritesheets, via TexturePacker?
Not really - firstly this still has the same problem: as soon as you edit anything Construct will throw out the old spritesheets and create new ones, essentially undoing anything that was done in TexturePacker. Secondly Construct sometimes packs spritesheets differently depending on project settings, e.g. downscaling quality. If an external tool does not respect this setting or provide it as an option, it's incompatible with that project setting, meaning Construct has to either re-pack the spritesheets itself (again undoing anything done by TexturePacker), or ignore the project setting (creating the possibility of issues like graphical glitches that appear if TexturePacker created a spritesheet without using the same algorithm Construct does in high-quality downscaling mode).
I think the best option would be to be able to choose which sprites go into algorism, an option within the properties of the sprite would solve all the "problem".
So presumably you'd want to configure this to reduce memory use. In that case it's even better if Construct can do this automatically for you. We have an upcoming change designed to do exactly that.
Maybe set a max spritesheet size?
I was going to add exactly this for the next beta cycle - I've already tested it and it seems to be the single thing that makes the biggest difference (moreso even than packing objects that are used together on the same sheets). It's a shame this can't be detected automatically - I want to try to avoid ending up with loads of advanced project settings that all need to be configured just right - but at least the option's there in case you need it.
I am sceptical that adding any other more options would be useful. Packing spritesheets is actually a far more complex and subtle process than most people imagine. You might just think it means "throw a lot of images on to one larger image". Suppose you then start downscaling images a long way with mipmapping enabled (which it is in Construct for best quality rendering), and find that bleed happens on the lower mip levels. Turning off mipmaps is actually slower, so is not a good solution. Adding padding at first looks like it solves this, but actually just postpones the problem to a lower mip level, where it still happens. So then the best approach is to position and pad at power-of-two sizes so only the very lowest mip levels exhibit any bleed. Then you find transparency still bleeds in to the edge pixels. So you need to repeat the outer pixels of the image. Repeating it once doesn't solve the problem for low mip levels, because transparency still bleeds in again. So you need to repeat the outer pixels until they fill the entire power-of-two sized cell it's been placed in. Then for good measure, center the image within that.
This is just a single aspect of spritesheeting, regarding resizing smaller. It has been directly informed by bug reports from real users with real problems. There are many other caveats involving memory usage, efficiency, compatibility, rendering quality, etc. I think this has led Construct to a more sophisticated spritesheeting algorithm than other tools. For example I don't think I've seen any other tools that provide an option for automatic power-of-two padding to solve the mipmapping bleed issue. Providing a customisable padding is the first-level solution to that, but doesn't really solve the problem properly; the power-of-two padding is the second-level solution that we've ended up with. So to me this looks like they have not yet run in to all the same issues as we have yet, so have not developed the algorithm as far along as we have. This is the case in other areas too, such as repeating the outer pixels in to the padding to avoid bleed either between other images, or with the transparent background of the spritesheet, since it ensures even fractional texture sampling right at the edge of an image returns the same color pixel.
On top of that, AFAIK there's no reason to keep spritesheets square, it simply wastes memory. It's impossible to keep everything on one sheet, because eventually you hit the maximum texture size limit - avoiding that makes multiple spritesheets mandatory. And so on.
In short I think we have a much more refined and well-developed spritesheeting engine than most people think. Adding more options unnecessarily burdens users with difficult technical choices with tradeoffs they might not understand, and in some cases are wasteful or unnecessary. Since it makes a big difference I think the max spritesheet size is the sole exception to this. It'll turn up in the next beta cycle so you can try it out.