Individual pieces would be identified by "<Author>/<Style>/<Piece>".
I think this is a good way to do it, yeah.
You have an interesting point about multiple people having graphics sets of the same name. Allowing the meta-info file for a graphics set to specify a graphics set which this set is an extension to allows to maintain authorship for each individual tile. In lix right now, if you add a tile to someone else's tile set it will go into the original creator's folder and not in yours.
Images for each resolution. (What's the best naming system to differentiate?) Only one resolution is required.
Considering your point about the pre-extensions in like, e.g. tile.S.png specifying a steel tile, I wonder if this could be all avoided by rather than sticking to naming schemes, there could just be folders called "1x", "2x", "mask", "meta-info". For most terrain tiles, you'd only have one resolution, no mask and no meta-info, so just dumping a bunch of pictures in the 1x or 2x folder would give you a working tile set sans objects. meta-info would contain text files specifying if a tile is steel or whatever else it can be, and defaults to non-steel/whatever is most common if no meta-info is present.
Should there be some kind of choice here, where it can either be a strip, or seperate images for each frame? The former would require explicitly specifying how many frames.
In lix the former is used and the number of frames is auto-detected as there's a border around each frame. Not sure if this is the best way to handle it. The number of frames can be written into the meta-info file which has to exist anyway. I think eidcut can convert a strip into a sequence of images, but some authors might prefer one, some the other, so supporting both might be handy. For the list of separate images, should then a subfolder of "1x" exist, named like the object, that contains all its frames? And should those frames follow a numbering scheme, or should each of the images be specified in the meta-info file?
Some other questions:
Alpha handling, how to determine what is solid and what isn't? If full alpha pngs are going to be supported, this is an interesting question that also pertains to LixD. Should a mask actually belong to a terrain piece? I was wondering, if full alpha blending is supported for level design, then overlaying a lot of low-alpha (almost transparent) regions will give a high-alpha (almost opaque) region which would still be non-solid as none of the original regions were solid. Should just a bitmap for the whole level be created internally, anything pixel that, at the end, has alpha-value >= 0.5 is solid, and anything that has alpha value < 0.5 becomes non-solid, and maybe even overwritten with the background color to reduce ambiguity for the player? I don't know what the best solution for alpha handling is.
If a graphics set exists for 2x, and the masks are inferred from the images, and now someone adds new 1x tiles, this might change physics. (Not sure if this is ever gonna happen, I mean who would downscale 2x images for this?) Should the graphics set meta-info file allow to specify which resolution to infer the masks from, so that in this case it would infer from the 2x imagery instead the newly added graphics?
Tiles that are partially steel: As mentioned in another topic, do we really need this? One use I can see though is VGASpec levels that use steel, as mentioned somewhere. It's a bit cumbersome for these, but I can't think of a workaround that doesn't introduce new functionality (like a traditional steel area tile or something).
How, internally, should a level refer to a terrain piece/object it uses? Straight-forward answer: base path. (E.g. namida/forest/trunk, and the game infers that the image is in namida/forest/1x/trunk.png, the meta-info in namida/forest/meta-info/trunk.txt, etc). This works a lot more nicely in a text based level format as such paths are variable length of course.
Should sub-folders be supported for organizing tile sets better? For instance, my construction tile set has sub-folders for concrete blocks, wall pieces, metal rods, so the main folder doesn't flow over. Is this desirable? Implementation-wise it shouldn't be too much harder if tiles are referred to as described in the previous paragraph. If folders are used for different resolutions and meta-info however, and some tiles are in the main construction folder and some in the concrete, wall folders, the main folder would contain "1x", "2x", "mask", "meta-info", "concrete", "wall", the latter two having different semantics from the former 4 which seems a bit unelegant.