I'd recommend creating a utility or two which you'll actually find useful. Perhaps something like a color-picker where you could update the UI on a timer with an enlarged portion of the screen which is under the mouse and draws the pixel color, hex, rgb, html values about that pixel. Would help you learn about drawing within your window (or controls if you prefer), mouse capture, click handling, key handling if you set up some hotkeys. Helps to learn desktop/screen DCs, window sizing, painting.
An alternative which I created was a window I could drag around by clicking anywhere within the window. I changed the window styles to turn of the caption bar. On a timer, I printed out the Process, HWND, window name, etc. of the window which has the active window and input focus. I use this for debugging focus issues. Helps with styles, mouse, timers, drawing.
If you want to create an autoclicker that globally makes your mouse click, yea win32 API is your only choice, there is a sourceforge opensource application called "fastclicker" that shows how to implement that (along with old-school windows graphics implemented).
But personally if you just want a general purpose graphical project, there aren't many things that a portable library can't do, like SDL2, glfw, sfml (AKA hardware rendered for games), and QT, fltk(AKA event based UIs), and the things that it can't do make sense because why would you want to make a auto clicker when you can just use a tool already made to do that.
SDL2 is capable of what you have mentioned, implying that programmatic keystrokes and clicking can be interpreted as "queue a key event into the polling function of the current application", but I would consider that to be hacky-code and there is probably a cleaner alternative (just call the function that a keypress would have made instead of forcing a keypress).
But "programmatic generation of drag-and-drop", I don't see what you mean by this? I can see the purpose of a fastclicker, but in which context would you ever need this?