SmileBASIC doesn't mind! Labels defined within a function are considered local to that function, and do not count as duplicates if the same label is used elsewhere.
Tip of the day! Label scope.
The more structured your program is, the less need you'll have for labels. But what happens if you need a label in a function and you accidentally reuse a label from your main program?
As for your B array, I'm guessing it was defined in the program file that's using this library. Unfortunately, your library can't "see" any variables that were defined outside of it. Either you must pass B into INIT as an argument and work with it there, or you must define B in your library and set up COMMON functions that allow other files to access it.
I was having this exact problem. This is a screenshot of the library, yes? So you're including it from some other program file?
I found that I had to use EXEC "PRG1:LIB" instead of USE "PRG1:LIB". This allows the library to define its local variables. They remain in memory, but they can only be accessed by the library's functions. That should solve your A array.
Did you want to do keyboard entry that won't put messy text on the upper screen? Try looking at the 5th page of help for the DIALOG command. It's limited keyboard entry that doesn't mess up either screen, good for simple things like name or number entry.
If you're trying to do anything like INKEY$, well... I don't know how to help there. Might have to make your own keyboard.
It's probably best to just pick one screen mode and stick with it. I'm guessing that you want to use INPUT? An INPUT command will automatically replace the lower screen with a keyboard and then return it to normal when it's done.
Your second loop is blinking because you're clearing and rewriting it every 1/12 of a second.
Try it like this. Put your text outside of your loops and use vsync for timing instead of WAIT.
If it's:
@LOOP
GOTO @LOOP
breaking out is as simple as GOTO @SOMEWHERE. But if you're using a looping command (WHILE, REPEAT, FOR) you should use the BREAK command to end your loop and free up the memory that the system uses while running those kinds of loops.
You also have to check for special events that change the state of your program - if the player goes through a door or finishes a stage or is defeated by an enemy, etc. and move to different loops throughout your program accordingly.
As far as breaking out of a loop, yes, you can do it if you need to, but how you do it depends on the kind of loop you've got.
Here's an example of how I structure my programs:
Set initial conditions -- draw the screen, set variables, etc.
Do this forever:
Check inputs -- buttons, touchscreen, whatever I'm using
Change data based on inputs
Calculate new positions for onscreen objects based on data -- how far does everything move in 1/60th of a second?
Move onscreen objects to their new positions
Repeat.
In this language, the CPU will only ever run one command at a time, going down the line in the order you wrote them. If it seems like the system is doing several things at once, it's because the program was organized so that it would do a little bit of everything for every frame of animation.
BGOFS, SPOFS, and LOCATE change the screen positions for background, sprites, and printed text, respectively. If you check the help screen for these commands, you'll see that there's an option to position these things along a Z axis. A negative Z value makes things pop out of the screen, and a positive value pushes them into the screen.