Was it a conscious decision to:
I can perhaps understand 1), although I don’t think it’s really necessary, but having No precede Yes is not consistent with UI convention. I would support changing this.
Edit: just tried deleting a file in Windows, and surely enough, Yes is selected by default.
You want to have a general Yes/No default convention discounting the context?
There are two issues here. First, I think that under no circumstances should No be placed to the left of Yes. It’s not No/Yes, it’s Yes/No, at least in English.
Whether the UI should pre-select Yes or No for the user depending on context (is that what the OSMC skin is currently doing?) is a separate issue that could probably benefit from more discussion.
So, let’s concentrate on the No/Yes questions … where do you see them in the OSMC skin?
Any examples, screenshots?
One example I’ve seen is the file delete prompt in file view.
Are there other examples in OSMC skin and have you read this OK-Cancel or Cancel-OK? The Trouble With Buttons?
Thanks for the article, that was useful. I am not a Mac user and had no idea that Apple used Cancel/Save in that order. I can’t think of other examples in the OSMC skin right now.
I would argue that Yes/No is still different from Cancel/OK or Cancel/Save, because Yes/No is just a natural order in the English language, e.g. it’s always “a yes or no question,” never “a no or yes question.” I think the only time I’ve ever seen “No/Yes” was in imported Japanese video games. To me it feels unnatural and confounding in a UI.
Also, if my memory doesn’t fail me, the Kodi skin used Yes/No.
“No” is meant to take precedent for safety reasons… With e.g. a laggy IR remote we don’t want people to accidentally delete files or change things without being able to reconsider using the confirmation dialog.
In light of this, it makes very much sense to have the preceding option on the left (as would other skins or Windows do with the preceding “yes”).
Other skins may take a different approach as does Windows which you mentioned. But that approach doesn’t make sense in our opinion, so we won’t change anything about it. Sry 
The safety reason argument somewhat makes sense, although that comes at the cost of an extra click every time someone wants to delete a file (not to mention that you’re patronizing the user who presumably knows what he’s clicking).
But this part of the explanation does not make sense:
The reason Windows shows Yes first is not because it’s the default option. It shows Yes first, because Yes always comes before No.
I don’t see the logic of going from forcing a default to changing the order of words.
Whatever the default selection is, it should not guide the common-sense word order in the menu.
“No/Yes” is unnatural, looks bizarre, and breaks convention established by every XBMC/Kodi skin from the last 14 years.
You’ve received a definite reply which reflects the design/button order choices made by OSMC for our skin. If you don’t like this, you may use a different skin.
Or what you can also do: Fork the skin from the GitHub repo (as it’s open source), change the button layout/precedence to your liking and use your customized version of the skin.
Unfortunately we’re not able to satisfy the needs and wishes of all users. I will close this thread now as the discussion won’t go anywhere from here.
I think another problem with this is that people have got used to No/Yes. A lot of users stick with the standard OSMC skin. If we change this suddenly, and users intuitively press a key to select Yes, or expect No to be selected automatically, it could cause a lot of problems.
@Chillbo You may do as you please, obviously, and I will consider switching skins.
However, this is not about the needs of any specific user. This is basic common sense, and if more people start using OSMC (and care enough to report it here), you will hear about this issue again and again and again and again. No/Yes is very weird. I really don’t see how anyone can dispute that.
We’ll see… Until then nobody here will tell you that you can’t have that opinion, but without more people asking for this, we’ll rather keep things as they are.
Understandable. However, it’s never late to revisit an old decision, especially if that decision was not informed by basic GUI convention or discussed thoroughly at the time it was made. It’s not like this issue will go away as the time passes.