Hey there. I saw your message on my profile and realised that I had been meaning to reply to this thread (blame the awful new forums with less features and such…) XD So… I’ll do it here as it may benefit other people considering the marketplace haha.
First question…
There’s a few different approaches used here by different sellers.
Approach #1 is just to maintain the asset with as few versions as possible. Epic require that you keep it up to date for the current version and two prior versions. Meaning that if your product comes out with 4.17, you will need to keep a 4.17 build until 4.20, when you can drop 4.17. New assets don’t need to be supported on older versions than their release version though.
Approach #2 is to update it with every version and maintain them all the same. Obviously this is the ideal scenario in terms of ensuring all your customers get the best product they can get, as some people might start a project in one version, and that project may take a couple of years but they may not update the engine version of the project. This way they get any future bugfixes and such you might create. However, this is also the one that takes the most work if you are continuing to add to your product and fix bugs etc.
Approach #3 is to update it with every version, but drop new features on older versions. This is the compromise option, where you might have a couple of active indev versions, but you don’t completely drop the older versions of the engine.
Personally, I use approach #2 for most of my products. This means that with some of my assets I have some quite old versions that I work from, and when I release an update I need to apply that update, and ensure it works across every supported engine version. For example - my asset Quest Map and navigation System came out with support for Unreal Engine 4.10 onwards. When I apply bugfixes or updates, as I did recently, I work on the 4.10 version. Once I have finished, I go through and convert it to 4.11 and make sure that nothing breaks in 4.11. Then I go to 4.12, etc. until I reach the current version. As long as it all works without any changes/errors, you can actually just give Epic the 4.10 build and tell them that it works across all versions of the engine and that’s fine - the launcher will automatically do the conversion for you. However, in many cases there are warnings with deprecated nodes, or major engine rendering changes such as the changes tot he tone mapper, that may mean you need to have a version for different sets of engine versions. As an example, you might have a build that works from 4.10 to 4.12, then another specifically for 4.13, and then one more for 4.14 through 4.17. It really depends on the asset and the changes that may or may not affect it, though in MOST cases you can usually get away with one or maybe two versions of the product.
I have, however, had to use approach #3 in the case of the Multiplayer Survival Game Template, simply due to the sheer size and complexity of the pack. There’s a heap of things in UE that struggle when you got through engine version conversion. For example - using large datasets with datatables, as with the inventory data in the template, has a tendency to corrupt on version updates. As a result I’ve dropped updates for older versions of the engine aside from the current version and the one prior. It’s frustrating and I don’t like doing it, but it’s really something that has to be done because, for the most part, I am actually running simultaneous development builds of the template - updating each version manually by reapplying the work in each build. This is the only asset I do this with though, and I’ve given ample warning of this (it hasn’t happened yet - the next major update will be the first time I drop a version).
TLDR; it depends a lot on your specific asset. But there are a variety of options available 
Second question…
Blueprints require a blueprint tutorial file within the project as far as I know. This may have changed recently, as I know there was talk of dropping this requirement - but with both of my most recent submissions it was required. As such, this part, at least, needs to be available to the reviewer as it will fail submission if you do not have it. These tutorial files are annoying as hell to make, so make sure you give yourself some time to do it haha.
As for extended documentation/video tutorials - I make them after I have submitted while the product is going through review, and then continue to do after launch if necessary. As a general rule - if it is something that needs to be in the project, the reviewer needs to see it. If it is external you can tell them it’ll be available by launch.
One note - I haven’t submitted anything in a couple of months and it appears that some changes have been happening. So I can only provide info based on my experience. Yours may vary. If you do get knocked back from submission, as is very common, be sure to email them back and ask for detailed reasons why so that you can address them and resubmit
Hope that helps!