You can chain RGB and RGBW LEDs - I know you can do it if they're all SK6812, and I suspect but am not certain that you can also do it with mix of WS2812 and SK6812, but haven't done it myself (iirc, there are slight differences in the range of timings they will accept). The project where I did this is here LEDCTRLA/CanLightTest.ino at master · SpenceKonde/LEDCTRLA · GitHub - but it is, ah, not the most comprehensible code for you, I don't think... in short, it controls a board with 37 LEDs in concentric circles of 18, 12, and 6+1 in the middle, and the inner one is a set of 3-channel WWA (warm white, cool white, amber) SK6812, and the inner and outer ones are RGBWW (warm white) and RGBW (cool white)
The catch is that when you do this, controlling one of the type types will be ugly as hell, because - say you have defined the strip as RGBW and have your 7 RGB's on the end...
All will be well for the RGBW string (say it has 100 LEDs, 0~99, 400 bytes of data). Now you have 7 RGBs - those need another 21 bytes of data.
So you would tell the library that you have 106 LEDs, numbered 0~105, 424 bytes of data. So the first three colors of LED 100 would correspond to the first RGB LED, the last channel on LED 100 and the first two on LED 101 will be for the second RGB LED, and so on, and the last three colors on LED 105 will be ignored.
So yeah, it's ugly, but it can be done. When I do this, I don't use the abstractions for setting pixels provided by the library, and just directly write to the frame buffer, with stock Adafruit_NeoPixel library, getPixels gives you a pointer to the uint8_t array of pixel data (remember, it's a pointer and you need to treat it as such). My Adafruit_NeoPixel_Static library trades support for dynamically adjusting the length and instead you declare the frame buffer and pass it to the constructor - this saves a significant amount of flash if you aren't otherwise using malloc()/free(), and also makes the ram used by this frame buffer show up when you compile your sketch, so you don't have to be like "okay, it says my sketch uses 1600b of ram, but I know I have a 424b frame buffer, so it actually uses 2024b, and with only 2048b available on the '328p, i don't have enough left for call stack and local variables". Either way, by writing to the frame buffer directly, you can make your own functions to set color of LEDs and correct for the above-mentioned complication with the number of channels per LED, because you know which LEDs have how many channels.
(the static neopixel library originally came out of a project where I was desperately scrounging for available flash - my cores for ATtiny parts now have a more tightly integrated one that saves a bit more flash for those resource constrained parts, at the cost of having to choose the port from a tools submenu)
In any event, a nano or pro mini would be fine for this.