Before, timelines used to enforce a single block per element track rule. When that was the case, child blocks and keyframes were directly attached to their parent block. Stuff outside of a parent block's bounds were greyed out, and moving the block moved its content below.
After that, we changed that single-block rule to a multi-block one, to allow a single video layer to be played more than once in a timeline. It made sense to offer that possibility to users. But that broke the direct dependency to the parent. We are in a state today that's in between two thing; to enforce the keys to act like they are the child of the block above them without actually being owned by that block is a lot of small rules, kind of a hack and not future proof. To have the keys owned by the blocks is a big (and costly) refactoring that will eventually come, but we are waiting for more feedback and focusing our energy on maturing other aspects of the timelines. Like you've noticed it is a big folder and a lot of aspects of it are still far from perfect 
Hope that makes sense !
Oops, we lack documentation on this one. I'll update it right now !
Here are the timeline shortcuts:
J to Jump to previous key
K to Jump to next key
Ctrl + click = Add clicked element to selection
Alt + click = Change keyframe interpolator
U = Switch tracks / curve
left / right + (shift) = Move selected keys forward / backward in time 1 (or 10) frames
Ctrl + (shift) + left / right = Jump 1 (or 10) frames forwards / backwards
Alt + K = Create keyframe / track at current time
About the shortcuts that are not in there:
Jump to scene start / end - You mean timeline start / end ?
Jump to clip start / end - and there block start / end ?
I'm adding those in our internal issue system:
Jump to timeline start/end: i / o
Jump to previous / next block: j / k - when selected track is an element track (blocks), not a parameter track (keyframes)
For the global shortcuts (out of the timelines editor), we'd have to introduce a concept of "Main timeline" (like the main camera in a compo) to handle conflicts when there is more than one timeline.
I think we need a discussion about this one, not sure if everybody would be happy that the space bar controls the timelines globally, meaning we couldn't use it for something else (currently to activate / deactivate elements). What do you think @vincent.armongn, @Francis and everybody else ?
Indeed, when the playhead is controlled by the user, trigger keyframes should not fire an event. I will look into this and if there are no particular reasons it is that way today, I will add it as an issue.
Might be a bug indeed... Tried it here on my version of Smode and it works perfectly.
Can you provide me with a scenario to reproduce this, the simplest and most straight forward starting from the creation of a new compo ? That might help me track the bug ! Thanks
Well, today the parameters of the element are never selectable from the timeline. What happens is, I think, when you select a track with a block in it, that block gets selected and what you see in the parameters are actually the parameters of the block itself.
Today, blocks and keyframes display their parameters in the element parameters view on the right. That might be something we need to change, and offer a dedicated parameters view for objects that are inside the timeline. If we do that, it might be possible to do what you say and show the parameters of the element animated by the selected track. that might clarify the whole thing and allow for the quick access to parameters you talk about, which sounds like a good idea !
But until the keyframes and blocks have their own dedicated parameter view, I'm afraid it would only confuse people more. I think timelines would clearly benefit from that though, so I'll create an issue to do both the things mentioned above.
There is a ton of clarification to do around vector objects indeed ! This is the next thing I'd like to work on on timelines. I'll keep you up to date on that one
That one is in the idea basket for a looong long time haha !
We are thinking about it, unfortunately that basket is quite full - that's why getting feedback and request from a lot of people would help us prioritize and get out the features that will be used a lot
