I notice that when Glyphs generates /iogonek/, it is built from /dotlessi/ + /dotaccent/ + /ogonek/. Why not /i/ + /ogonek/ instead?
I guess in most cases the tittle of /i/ and the /dotaccent/ will be identical in size and placement, but if they aren’t, I would think the /i/ recipe would be better.
I disagree: i itself is correctly made from dotlessi + dotaccent because it should be the same height as the dot accent anyway. For instance, in Polish, ż (zdotaccent) and i should have the same accent.
If you want to do it differently, you can still do so (just add i as a component), but it won’t look right in quite a few languages.
For what you suggest (i with different dot), I’d make an i.ss01.
if you build it from i+ogonek, it will have a nested component and that mean you can’t easily move the font to .ufo or Fontlab. There are other places where you can’t avoid this but if I can I try.
And, as the ogonek is positioned with a anchor, the placement of the anchor would be placed next to the component and if the dotlessi changes it would be misplaced.
That means that it is better this way 
I disagree: i itself is correctly made from dotlessi + dotaccent…
No it is not. In heavy sans faces with a tall x-height the tittle is often a long rectangle that cannot be used as a dot accent. And most people draw i before they start drawing accents, so having i rely on the existence of a dot accent glyphs is completely impractical.
if you build it from i+ogonek, it will have a nested component and that mean you can’t easily move the font to .ufo or Fontlab.
Only if i is built from i + dotaccent, which it often should not be. This needs to be changed. This thread also exposes a flaw in the design of Glyphs; the files that control this behavior do not belong inside the application package. Fontlab puts them into external files so that users can customize them without changing the application package. Glyphs should do the same.
Of course, this is a design question, and open to some extent of interpretation, no question about that. But I still contend that the i dot should have the same dot as the dot accent, whether you build it from components or not. Practical example: Polish uses a z with dot accent. It should be the same height and shape as the i dot (see Adam Twardoch’s explanation), and that’s just Polish. In short, if you have different dots in the font, you run into consecutive problems in some languages. If I really need an i with a different dot, I make an i.ss01, so the user has the option to pick what looks right for her.
I don’t see where the flaw in Glyphs is. Glyphs does not force you to build the i from components. But if you do, it’s logical that it’s built from dotlessi + dotaccent. What else would you want to build it from?
The component definition is meant as a starting point. if you do not like it, you can easily change it.
For the i components: The dotaccent is not always the right shape for the i. If you do not like it, you need to define another glyph with the shape you like. Until now, I tried to to add custom mark glyphs to the glyph definition database but I just as well do it. Any suggestions for a good name for the “dot for i”.
And you can define your own glyph definition.
open the file Glyphs.app/Contents/Frameworks/GlyphsCore.framework/Versions/A/Resources/GlyphData.xm l
copy the lines you want to change (and of cause the xml header and footer), change it and save it in ~/Library/Application Support/Glyphs/Info/GlyphData.xml
Then the info your file will overwrite the default settings.
Just came across this thread because I was having similar confusions. I tend to use dotaccentcomb.narrow to build the i and the j. this way I can keep for example gdotaccent and i separate since I also like to prefer that… and this seems to work well for iogonek, it pulls dotaccentcomb.narrow if it exists… (also this is an 8 year old thread, so the .narrow could be a newer function and this could not be a problem anymore.)