A very difficult sidebar to organize. Great you're having another go at it. Here are my thoughts:

@Richard Antalik (ISS) - If you have a moment while going through the VSE functions when updating the manual, could you check the values in the "Timecode" Panel, if they make sense to you? For me, several of them do not. Here are my notes:

• Is it correct 'frame_start' should show the mouse position in relation to original insertion point(or something like that)? - this value is no longer used in the panel.
• 'frame_end' seems broken(not used in panel).
• If the Hold Offset Start is less than the start point of Strip Offset Start, and Strip Offset Start value is changes it will jump to zero, and if extended to the left the hold part of the strip will not be drawn, until the Hold Offset Start value is changed.
• The 'Strip Offset End' shows the number of frames to the end of the source material, this is not very useful in the UI. Ex. to get the strip end to extend to the right(make it longer) you'll have to drag to the left(opposite direction) to decrease the value.
• The Hold Offset Start/animation_offset_start seems completely off. It extends the strip in the end, not in the start.
• There are commented out hold frame duration values in the code.
• Several of the values can be illegal, causing the strips to turn the 'inside out".
• The panel titel "Timecodes" can be misleading - because often time codes means in most cases file embedded time codes. This panel is just Transform values written in SMPTE and frames - and not time codes.

The contents of SEQUENCER_MT_change seems to have been moved into the Input menu in this commit: D2665

This is the width of the VSE sidebar panel from a build I downloaded 19/5 called blender-2.80.0-git.06c4139a6833-windows64:

This has been fixed by D5065.

The following Text Editor Redesign is the result of further discussion with @William Reynish (billreynish)

Pre 2.80 users could only import Movies through the Add menu and therefore they where always was exposed to the import options. With the file browser in the default VSE workspace missing the import settings, most people will never know the existence of them, causing a bad experience.

This patch has been included in this more comprehensive timecode panel fix patch: D5065

Just checked 2.73. Same bug.

The problem is not in the panel, but in the frames to SMPTE conversion.

I can confirm this bug.

Just removed "bpy." - not needed.

Turned the toggle-buttons into checkboxes.
Renamed Properties to Display
And Show Margin will determine visibility of Show Column:

Yes, there are many things which could be improved, but on the things you mention, most of the functions are still defined in C here:
https://developer.blender.org/diffusion/B/browse/master/source/blender/makesrna/intern/rna_space.c
... and I'm not able to code C. I'm sorry.

Can confirm this bug. Ctrl + drag for snap makes strip overlap:

That would make it so much more clear. If Location would have it's own sub panel too, users wouldn't think, the alignments are presets for the Location values.

You should add a 'Video Sequencer' tag to your bug-report.

A note on the scaling causing slow fps. If footage is scaled to fit project properties, it will cause a much slower playback, which is why the 'Set Render Size' should be exposed among the menu evoked filebrowser's import settings and all of the movie/sound/image import settings should be available in the default VSE filebrowser import settings. A gif to show the slow fps and missing import options:

I did discuss with Brecht way back about the naming of some of these functions and if I remember correctly he preferred something along these lines: SelectStripsUnderPlayhead and SelectStripsInChannel, as compared to SelectCurrentFrame and SelectChannel. Or do you mean CutHardAndHold vs. Freeze Frames?

Removed whitespaces.

I wish the Blender text editor would have a 'Remove Trailing Whitespace' feature or a feature to show invisible characters. Anyway, when I remove the whitespaces, it is not enough for Sourcetree to detect any change to make a patch. If I add a commented letter, only that letter will be included in patch. I'm confused, did you already submit this commit? (This is my first attempt to do this patching stuff...)

Waveform toggle removed.
Deinterlace is back in the menu.
So is Rebuilt proxies...

I came across this old patch: https://developer.blender.org/T6882
This patch adds the ability to select the adjoining handles on adjacent strips with a single click.

This problem and also this T64579 in many ways, relates to the current workspace of the Sequencer, because it has introduced a filebrowser, but where the Menu > Add > Movie/Sound/Image opened file browser had import settings, the current Sequencer filebrowser has none.

Testing your operators by calling them from the Menu: Preview Selected(nothing happens in the end point), CrossfadeSounds(disabled) and Concatenate(error) are broken - the rest of the operators are working.

Maybe unrelated to this question, but channel numbers and time codes can overlap, and become unreadable:

Sorry for being late. Here are a few suggestions for the sequencer startup presets:
(from: https://devtalk.blender.org/t/suggestions-for-vse-ui-cleanup-and-default-settings-in-2-8/2210 )

DAR is the final displayed aspect ratio, FAR is the frame aspect ratio, and PAR is the pixel aspect ratio.

DAR = FAR * PAR

Ex.

DAR = 720:576 * 16:15
DAR = 720 / 576 * 16 / 15
DAR = 1.33...

Trouble is that DVD material both needs a PAR and a DAR correction to look correct on a computer:
https://en.m.wikipedia.org/wiki/Pixel_aspect_ratio
https://en.m.wikipedia.org/wiki/Display_aspect_ratio

You can use the EDL export add-on(imports in Resolve) for Blender: https://github.com/tin2tin/ExportEDL
Or export an EDL from ex. the freewares: Resolve, Shortcut or Flowblade or on Windows only, this can be used: http://www.frogsoft.com/edl_toolkit.htm

As long as OTIO is not directly implemented in Blender, EDL (cmx 3600) is the only way to import/export the VSE timeline to/from other applications ex. Resolve, Premiere, Lwks, Final Cut, ShotCut, Flowblade.

Testing the various operators:

I'm must confess that I'm not ready to give up on this yet... I've updated the space_sequencer.py according to the renaming in your version of the operator file:
https://github.com/tin2tin/blender_vse_reworked/blob/master/UI_fix_space_sequencer.py
If you want to edit the space_sequencer.py file from the Blender text-editor, several additional files needs to be loaded into the text editor to avoid errors. They are opened in this .blend:
https://we.tl/t-uWQSc01EbV

In D4199#95636, @Richard Antalik (ISS) wrote:

In D4199#95618, @Peter Fog (tintwotin) wrote:

I feel that info about the shift/ctrl/alt functions should be in the status bar and context-sensitive, so ex. when hovering over a checkbox is should say +alt will add values to entire selection(if that is not the default behavior).

Not sure - this information would how on every editable element, so it would be kinda redundant.
On the other hand it is quite essential information - perhaps it should be shown in status bar, where LMB icon is

In D4199#95594, @Richard Antalik (ISS) wrote:

• SEQUENCER_OT_Move
  • What about moving to nearest snap points(another strip start, end, markers, channels etc) in desired direcion? I got this coded, can move large blocks, but need better collision handling(need this anyway, so why not...)

Ctrl+drag playhead/strip will snap to next cut, so snapping with Ctrl pressed would be in consistency, but the default move should be without snapping.

• How to handle collisions? What should happen when you do ripple delete and attached effect in upper channel would collide into some strip?
  • prevent execution and throw error?
  • move as far as possible?
  • configurable behavior?

When pasting, stips will be inserted into the first free channels, so maybe when strips are colliding they should be moved upwards into the first free channel(but only if it is effect-strips).

• What should be behavior of strip lock?
  • prevent any modification other then changing lock state?

Yes, I think so too.

Another thing, that I wanted to tackle was displaying and modifying properties of selection.

• I was thinking about concept of active strip - my brain refuses to accept it's usefulness. Maybe because active strip is completely independent of selection.

Maybe all select-operators should ensure that the active strip is always the last selected strip, which it is when you select manually. The question is if you deselect all also should deselect the active strip(and close the strip properties panel?). That would be an understandable behavior, but I don't know if it will be annoying to have the panel open and close all the time?

• Alt + tweak value and alt + enter seems to work pretty well so nothing to do here I guess

I feel that info about the shift/ctrl/alt functions should be in the status bar and context-sensitive, so ex. when hovering over a checkbox is should say +alt will add values to entire selection(if that is not the default behavior).

Displaying properties of selection could be done better IMO.

• Ideally you want to display all properties of all types. Logical step would be group properties based on strip type
  • use tab per type, so you can immediately see what types are selected and switch between them?
  • Not sure, if we can show only values of fields that would be same for all selected strips of the same type, otherwise they could be blank or display some label like "varies".

I don't know if this is too much trouble for now? How does the 3D View deal with selections containing different types?

• when I change active strip to strip of different type(from movie to sound), panel organization is quite inconsistent.
  • Don't know what we can do about this...

Yeah, the strips have quite individual settings, which makes it hard to avoid panels jumping around when changing type.

@Richard Antalik (ISS) Thank you for investing so much time in this. The "space_sequencer.py" doesn't seem to be updated to reflect the changes in "sequencer.py"? When I replace these two files in a fresh build of Blender the entire UI is broken. So I can't test your changes.

In D4199#95524, @Richard Antalik (ISS) wrote:

@Peter Fog (tintwotin) I should say, that I am modifying these scripts, so please don't make very big changes.

Sorry, I didn't know that. My son was jumping around me when I updated the file, so I feel that there might be things unfinished. the main changes are the split-extract/lift/remove,operator, navigation - range-start/end menu. Will not do more for now.

In D4199#95378, @Campbell Barton (campbellbarton) wrote:

Looking further into split operators SEQUENCER_OT_SplitExtract and SEQUENCER_OT_SplitLift duplicates functionality, with only one line difference: sequencer.ripple_delete / sequencer.delete_lift. This could be made into a single operator.

These functions seem to be already included in the 'Input' submenu:
'class SEQUENCER_MT_strip_input(Menu):'

In D4199#95377, @Richard Antalik (ISS) wrote:

Oh my.. Now I am looking at this thread, 100 inlines...
OK I will read through this and set this as a priority issue, which it actually is to be fair...

Thank you for updating the files. I can see the try/except wasn't removed in my Github, but they are removed now.

In D4199#95330, @Richard Antalik (ISS) wrote:

I will update files for this patch. As for my progress - I was reformatting keymap file, still have to compare 2 versions and remove items that has not changed.
I was planning to continue this work during the weekend as it can turn to manual labor, so during workdays I an happy when I can do few "one line" patches.

@Brecht Van Lommel (brecht) @Richard Antalik (ISS)
More fixes and comments here: https://github.com/tin2tin/blender_vse_reworked
Ex. View Channel Solo/All & Toggle All Modifiers have now been removed.
A lot has been fixed/addressed, but not yet everything.

@Brecht Van Lommel (brecht) @Richard Antalik (ISS)
Another round of fixes uploaded here: https://github.com/tin2tin/blender_vse_reworked
And now also added some comments below.

@Brecht Van Lommel (brecht) & @Richard Antalik (ISS)
Thank you for spending your time on this.
As I have already stated, I'm not a coder.
Most of the operators are reworked code from ex. KinoRaw. That's why the code-style differs.
I have made the first round of changes from your(Brecht's) remarks(mostly the cosmetic ones), and uploaded the files here:
https://github.com/tin2tin/blender_vse_reworked
(I don't know how to submit patches, sorry)

Thank you for this, @Richard Antalik (ISS)
The changes should work without changing the default VSE layout.

If you want collect VSE issues and such. Here are some links to public documents on bugs, papercuts and suggestions for the VSE:

If you want to test it against a (unofficial) 2.80 VSE panel, you can get it here: https://devtalk.blender.org/t/can-we-in-collaboration-produce-a-working-suggestion-for-improving-the-user-interface-of-the-vse/3264/77

I think this change will be problematic when adding more strips from the same scene using ex. different cameras. I personally do not want the scene-strips to inherit or be limited by any duration from the scene's preview/render ranges. That duration should only be determined by the length of the strip in the sequencer(and not limited to or changed by the range currently in that scene), but that's just my opinion.