I put my answers in-line.
1) The question that came up for me recently is how we model the grammatical
context for senses. For instance, "to ask" can mean requesting information, or
requesting action, depending on whether we use "ask somebody about" or "ask
somebody to". Similarly, "to shit" has entirely different meanings when used
reflexively ("I shit myself").
Not only that. "I shit myself" is very different from "Don't shit yourself". It is not just the reflexivity. It might the whole phrase.
Looking at
https://en.wiktionary.org/wiki/ask , we currently do not have the word "about" on this page. We have a list of different senses, each with usage examples, and that would work well in the current model. Indeed, the question is whether "ask somebody about" belongs here or not. "ask somebody their age" or "ask somebody for the way" works equally well.
We could also add this information as a special field in the Sense entity, but I
don't even know what that field should contain, exactly.
Just a usage example on the sense? That would often be enough to express the proposition.
2) The older question is how we handle different renderings (spellings, scripts)
of the same lexeme. In English we have "color" vs "colour", in German we have
"stop" vs "stopp" and "Maße" vs "Masse". In Serbian, we have a Roman and
Cyrillic rendering for every word. We can treat these as separate Lexemes, but
that would mean duplicating all information about them. We could have a single
Lemma, and represent the others as alternative Forms, or using statements on the
Lexeme. But that raises the question which spelling or script should be the
"main" one, and used in the lemma.
I would prefer to have multi-variant lemmas. They would work like the
multi-lingual labels we have now on items, but restricted to the variants of a
single language. For display, we would apply a similar language fallback
mechanism we now apply when showing labels.
I am not a friend of multi-variant lemmas. I would prefer to either have separate Lexemes or alternative Forms. Yes, there will be duplication in the data, but this is expected already, and also, since it is machine-readable, the duplication can be easily checked and bot-ified.
Also, this is how Wiktionary works today:
Notice that there is no primacy of either.
Having multi-variant lemmas seem to complicate the situation a lot. I think it is important to have only one single Lemma for each Lexeme, in order to keep display logic simple - the display logic which will also be important in tools like the query service and every place that displays the data, not only Wikidata. Multi-variant lemmas are a good idea if you have entities that you look at in a specific language - like Wikidata's display of Items - but it is a bad idea for lexical data.
Examples of why this is bad: how would you say that the British English version is the same as the American English? You use fallback so you don't have to duplicate it. But what is the difference for an entry that doesn't have a BE variant in order to reduce redundancy vs an entry that doesn't have a BE variant because it has not been entered yet. Statements and Forms, or a a separate Lemma would both solve that issue. Lemmas do not have the capability and flexibility of statements.
How do you determine the primacy of the American or British English version? Fallback would be written into the code base, it would not be amenable to community editing through the wiki.
Whether separate Lexemes or alternative Forms are better might be different from language to language, from case to case. By hard-coding the multi-variant lemmas, you not only pre-decided the case, but also made the code and the data model much more complicated. And not only for the initial development, but for perpetuity, whenever the data is used.
What do you think?
We shouldn't force for perfection and covering everything from the beginning. I expect that with the lexical information in the data, Wikidata will continue to evolve. If not every case can be ideally modeled, but we can capture 99.9% - well, that's enough to get started, and then see later how the exceptions will be handled. Also, there is always Wiktionary as the layer on top of Wikidata that actually can easily resolve these issues anyway.