This issue drives the general UI/UX design process while details are to be discussed in follow–up issues.
Related Editor Recommendations:
The first thing to be discussed is which sub–features will compose List experience in the editor.
Note: Not all UI/UX elements must be included in the very first implementation and the feature may be enhanced progressively over the time.
Which of the following is a good start?
list-style-type property, like "square", "upper–alpha", etc.). It can be either numbered or bulleted, with default styles.
list-style-type for particular indentation level).
This is actually the same as the previous one but both bulleted and numbered list share the same UI (a single button + dropdown; one item less in the toolbar). It could be confusing to the editor users but it's still something to consider.

Similar to https://github.com/ckeditor/ckeditor5-link/issues/17#issuecomment-242678613, a contextual balloon panel could be displayed when the user clicks a list item. The toolbar would offer editing options associated with current editing context, like indent/outdent buttons.
Beside indent/ourdent interface, the contextual could also bring some UI to change list type (like the access to the "list types panel") – not designed yet. I.e. if bulleted list is edited, the "list types panel" would offer types (schemes) for bulleted lists only.

I'm against contextual toolbar in case of lists. It would need to be visible all the time when you have selection in a list and this has several downsides like – being irritating, bad positioning options when a list is long, etc. I would use contextual toolbars only for objects like images and tables, and non-collapsed selections (like in link).
Regarding the button – I'm for 2 buttons (numbered and bulleted lists) with dropdowns (so a "split button" component). The most popular solution, most intuitive IMO.
I am against balloon panel, it would be really messy. You'd have that ballon during whole time while editing list, which is a lot.
I am also against single button for both numbered and ordered lists.
PS. I agree that in this case indent and outdent options may not be obvious if you don't have indent/outdent buttons in the toolbar (like CKE4 and GDocs have). But I think that this is ok to have such buttons.
Alternatively, we could add them inside the list dropdowns, but I'm afraid that this wouldn't be intuitive. It don't remember any editor which have them there. OTOH, none editor separates the concept of indenting lists and indenting paragraphs as much as we've done in CKE4, where those features are totally independent of each other (and in the std preset you can only indent lists). OT3rdH, if we'll ever implement indenting paragraphs, we'll need to introduce indent/outdent buttons and then they should work like in CKE4 (so also for lists).
Yes, I haven't mentioned that, but of course if we don't have indent/outdent buttons in balloon panel we need them in toolbar. Honestly, I don't think that implementing indent/outdent paragraph is something that we need, I see it as one of those features that can be easily cut.
As for now, I'm for:
If in the future we'll introduce list type, starting number, etc., we may decide to go with a contextual solution. Maybe, in fact, the toolbar may be too distracting, but a small "flying shit" shown next to the list which would them open the menu may be an option and may apply to many other features as well.
a small "flying shit" shown next to the list which would them open the menu may be an option
This is the attitude I expected see in your comments! 😄
a small "flying shit" shown next to the list

If we consider contextual solution, it should not be distracting, so I think that balloon solution like in the Link feature is a bad idea. We may go with "vertical" tooltip, that would be shown on the left of the list. This way it would be less distracting and easier to position.
BTW this reminded me about an article explaining that clippy's initial heuristic was meant to pop it out less often, but the business guys altered it and ruined the whole idea :D. So sad.
"vertical" tooltip, that would be shown on the left of the list
IMO the content is way too unpredictable (just like editor integrations) to assume that there will be space for such UI.
Another thing to consider: if we (eventually) go with the list type panel, then should it control the whole list structure for each level (like Google Docs, MS Word):

or just current (flat) list level context?

IMO the content is way too unpredictable (just like editor integrations) to assume that there will be space for such UI.
I agree. I can't imagine implementation of such a feature. The lists can be styled in various ways, with bullets outside or inside items, with different spacing, etc.
As for:
Another thing to consider: if we (eventually) go with the list type panel, then should it control the whole list structure for each level (like Google Docs, MS Word):
or just current (flat) list level context?
I'm for just the current level. The version with a whole list may work for non-HTML editors, but I sense lots of issues if we'll try to implement this in CKE.
This is the attitude I expected see in your comments! 😄
Well, I didn't want to design the thing, so I gave it the clearest possible description, for it to inspire you guys on the visualizing the idea proposed.
Btw, we agree that we're spending time here on something that should not land in the editor for a very long time, right? I mean, the possibility to configure the list type. So why bothering? It may endup that, in the future, because of the implementation of other UI elements, we'll have a clearer way to go with it.
Alright. So let's focus on https://github.com/ckeditor/ckeditor5-list/issues/3#issuecomment-243093364 first.
I consider this done.