I have to say that your code pieces are working with different input files (something maybe you overlooked?) - you need to verify each file that feeds the MERGE process using PROC PRINT or FREQ (and CONTENTS for that matter) using a WHERE (each individually prior to the MERGE) to confirm that expected input conditions are actually suitable for a merge process.
Suggest you add the following SAS DATA step diagnostic stmt to identify conditions with your merge process - likely you have a BY variable that is not contributing as you expect:
PUTLOG '>DIAG-nn>' / _ALL_;
where "nn" identifies a unique value when you have more than one of these statements in your SAS program at key points in the processing. Likely for you there would only be one for the over-simplified DATA step you demonstrated.
Also, highly suggest you read up on MERGE with BY statement processing and how SAS deals with contributing observations, variables and values -- both character and numeric. Also, removing any output format, if declared, may help you detect a difference in an observation with another.
The resulting data set will actually contain all fields from all contributing tables.
Where you must be very careful is when the same field exists in more than one table (something which might be the cause of what you observe).
As proposed: It's worth reading how the merge works exactly because there are some differences to an SQL join. That's a trap you can step in or you can take advantage of the differences depending on the case you have to solve.
beware a feature of data set options!
Any variable you name as the value of a statement option, like ( in= variable ) on a set or merge, will be dropped - it cannot be "keep"-ed.
So, make sure the in= variable does not have the same name as any variable among your inputs, that you want to keep!