Now I like to start a new feature2 based on feature1.C to continue work for commit D..K.
Since the work you intend to do on branch feature2 requires the commits on feature1 but are not yet in develop, then you can start working by creating feature2 off of feature1 as you proposed. The only caveat is that you cannot merge feature2 into develop until after feature1 is merged in, unless you are willing to merge in both all at once and skip the separate merge of feature1 into develop on its own. Based on the comments we will assume you wish to wait so you can do a separate merge of feature2 commits.
After feature1 is merged into develop, you can simply rewrite your branch similar to how you proposed:
Creating a new branch feature2 based on develop and cherry-pick commit D..K
Note you have a minor error there: you need to start with C instead of D (parent of the first commit) for the cherry pick range. You could also use D^..K.
There are a few different ways to accomplish this. With cherry-pick you'll need at least 2 (or 3) commands if you currently have feature2 checked out, or you can do the same thing with a single fancy rebase command. The end result should be the same so it doesn't matter which you choose:
# Assuming you've already done these first two commands
# git switch feature2
# git fetch
# Option: cherry-pick
git reset --hard origin/develop # or create a new branch like feature2.1 from origin/develop
git cherry-pick D^..K
# Option: rebase
git rebase --onto origin/develop feature1
Side Note 1: if you already created feature2 off of feature1 but later realized feature2 does not depend on feature1 and you could have started from develop but didn't for some reason, then you could rewrite your branch as described above immediately, and wouldn't need to wait for feature1 to be merged into develop before merging feature2.
Side Note 2: I tend to use origin/develop instead of develop so you don't have to keep your local copy of develop up to date all the time. In fact I usually recommend deleting the local copy of develop just so you don't accidentally use an old version of it when making new branches.
Side Note 3: It's possible that you will be able to do a regular rebase (git rebase origin/develop) instead of a "fancy" one using --onto. Whether a regular rebase will work depends on what happened to feature1 after you branched off of it. If the final version of it is identical to yours such that the commit IDs did not change and no additional commits were added, then you definitely can do this. But if anything about it changed, it will depend on what those changes are. You could always try it if you wish, or just skip directly to the "fancy" rebase which you may have to do anyway. Also, if you know feature1 is changing before it's finally merged into develop, you could rebase feature2 onto origin/feature1 to keep up to date with it so that your final rebase before you create the PR for feature2 into develop is more likely to go cleanly. However, you may also have to use rebase --onto for rebasing feature2 onto feature1, depending on how feature1 is changing.
By the way, the (perhaps minor) inconvenience of possibly needing to rewrite your branch like this is one of the reasons people try to avoid basing new work off of incomplete existing work, when possible.
